[LLVMdev] Feedback required on proper dllexport/import implementation

[Anton Korobeynikov]

> My primary concern is what needs to be added to preserve current
> compiler behavior where necessary. All the other approaches appear
> to involve adding flags or attribute to an existing linkage type, so any
> existing compiler codes that deal with that particular linkage type will
> potentially have different behavior.
Right. But normally LLVM API does not provide backward compatibility.
The point is to make good code / API, not to fix the broken one with
hinges and supports.

> DLLExportLinkage with ExternalLinkage+DLLExport_attribute, then
> codes that check hasExternalLinkage() will affect DLLExportLinkage
> symbols as well, which may or may not be the right thing.
In this case everything should work fine. If the behavior will be
changed, then we'll find some subtle bug hiding there for ages. normal
dllexport'ed functions are essentially external functions with some
additional semantics.

 > LTO::addDefinedSymbol() currently does not handle dllimport/dllexport
> symbols, but if you change the semantics of ExternalLinkage to include
> dllimport/dllexport, then you could potentially have changed LTO
> (although, that is not necessarily a bad thing; you just need to check
> those places to make sure the compiler behavior still makes sense after
> your change).
Right. The change should be thoroughly tested. Some fallout from such
invasive change is a normal thing, really.

> And some contributors who have not caught up with
> your change may still submit patches with the old semantics in mind,
> which seems prone to errors.
This is irrelevant here. They need to submit patches against ToT, so,
they will need to submit already "new" patches.

> If you really like your approach, I wonder if it makes sense to rename
> the existing linkage type to something different, e.g., OldLinkage to
> NewLinkage, so that future patches using hasOldLinkage() will have
> to check their codes to make sure they work with the new semantics.
The point here is that patches should come with tests. And this is how
we will make sure they will work with "new" semantics.

> I agree. Hmm that is exactly why I said that dllimport inline functions bear
> some similarity to the existing available_externally linkage. Maybe some
> miscommunication has happened? I will make a guess as to what you
> were saying.
This is yet another point of not introducing new linkage types :)
Almost all the stuff can be represented with current linkage types +
some modeling of additional dll semantics.

--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University