[PATCH] D18826: Add auto-exporting of symbols from tools so that plugins work on Windows

[John Brawn via llvm-commits]

john.brawn added a comment.

In http://reviews.llvm.org/D18826#414347, @chandlerc wrote:

> In http://reviews.llvm.org/D18826#412821, @rnk wrote:
>
> > Added Chris, pinging other reviewers. Personally, I think we should go the other direction: build a DSO for LLVM, a DSO for Clang, and have opt plugins link against that. This, however, requires us to get serious about annotating our public API boundary.
>
>
> I don't really disagree with you, but I don't know who is going to step up to do the (really huge) work here. Are you? If not, what do we do in the interim?


I had a look at doing this approach, but didn't as it does look like a huge amount of work (though looking at the amount of time I've sunk into getting this auto-export approach to work maybe it would have been better to just do the work instead of trying to be clever). There's also another problem, and that's global data symbols - if you build LLVM.dll using LLVM_LINK_LLVM_DYLIB and link opt.exe against it there are a number of global variables used across the dll-exe boundary that need to be arranged to be exported from the dll and explicitly imported by the exe (for function symbols you can get away with not explicity importing them, but that doesn't work for variables). Alternatively those uses could be changed to not use global variables e.g. have a function that returns the address of the variable and export that, but in some cases that looks impractical e.g. APFloat has several static fltSemantics members that are used all over the place, and passes have static PassID members used in inline constructors which would all need to be changed.

In unrelated news I've found some problems with the template handling in extract_symbols.py (it looks at the outermost name in the namespace but it should be looking at the innermost name) which makes it throw away some symbols that should be kept. I expect to have an updated patch sometime next week.


Repository:
  rL LLVM

http://reviews.llvm.org/D18826