[PATCH] D73508: [LLD][COFF] Fix dll import for thread_local storage

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 29 00:50:10 PST 2020


mstorsjo added a comment.

In D73508#1846241 <https://reviews.llvm.org/D73508#1846241>, @zero9178 wrote:

> If a wrapper function returning a pointer would work over dll boundaries then I think that would be the best way going forward.


Yes, that should work cleanly. In that case, there's no TLS access over the DLL boundary; you just have a normal function call to a function in another DLL, which then returns the address of the calling thread's copy of the TLS variable within that DLL.

> I will look into it! I have not encountered the multiple definitions error when building with shared libraries.

I don't remeber exactly which component it was in, it could have been in some component which isn't always built (maybe in some unit test, but I don't think I would have built those in that configuration anyway...) If it works fine for you (after fixing the TLS variable) I could give it another shot to see where I found issues.

> I have encountered one when building current trunk as static libraries but I saw that you have fixed that for clang 10 already (was related to comdat and TLS)

Yeah, the TLS variable exposed a bunch of issues relating to TLS access across object files, but that should be fixed now. But if it's accessed via a wrapper function, those bugs (that are fixed now) aren't hit anymore either, as it boils it down to the simplest case, a TLS variable that only is accessed within one single object file.


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73508/new/

https://reviews.llvm.org/D73508





More information about the llvm-commits mailing list