It’s not really a big problem. In the past I have had to merge my changes with the ongoing CLang changes to allow the ‘attribute((dllexport))’ to be permitted on objects for the SHAVE target. My approach was a little bit cheeky because I just tweaked/hacked the source to allow it for SHAVE too and all went well. But the changes in v3.8 from v3.7 are more semantically constrained and tighter bound to Windows and this approach no longer works.
The error I get is simply (I’m not using ‘__declspec’ syntax, just the GCC attribute syntax):
error: unknown attribute ‘dllexport’ ignored [-Werror,-Wunknown-attributes]
And I can fix this easily enough.
But since the ‘dllexport’ semantics are mostly what I want, it seems like a better idea to reuse it if possible than to add my own ‘iatexport’ attribute that more or less does what ‘dllexport’ already does. So rather than going in and making another set of ad-hoc changes to re-enable it for our target, I thought I would ask cfe-dev first to see if there was a better strategy before I “fix” it again only to find that v3.9 breaks my ad-hoc solution again, and v3.10 sometime farther down the road.
In response to Rafael Espindola’s questions:
What file format do you use? ELF?
I can see the point of dllimport (telling the compiler something is known to be external, even in a non -fPIC build), but how is dllexport different from a default symbol?
Yes, our target produces ELF files ultimately, though the compiler does not have an integrated assembler.
What I do with the attribute at code-generation is mostly treat it as an ordinary symbol, but I supplement their definitions with a set of data structures that when linked creates an IAT or Indirect Address Table that can be inspected at run-time. This is useful because the code running on the SHAVE cores is usually managed by an executive running on the Sparc Leon cores, and the dynamic lookup makes the programming model a lot simpler. The additional semantic checks and constraints that CLang places on ‘dllexport’ are also very valuable, as they make many incompatible or ill-advised use-cases become compile-time errors and warnings.
In summary, the CLang front-end semantics are very appropriate to my requirements, and my LLVM back-end emits normal symbols, but supplemented with the auxiliary IAT data structures.
It would be neat if I could “borrow” the existing ‘dllexport’ implementation for the most part, but in a structured well defined manner. I have had this working since LLVM v3.3, but each time I update to a new version I have to rework my adaptations, and going forward it would be good to have this better integrated using CLang best-practices rather than the ad-hoc I have used to date.