[cfe-dev] Looking for help with static initialization of thread locals (PR48030)

[via cfe-dev]

This is reiterating a message I sent out over a week ago on llvm-dev. I've unsuccessfully tried to address the issue in https://bugs.llvm.org/show_bug.cgi?id=48030 and am looking for help, as this is affecting some of our licensees. I'm reiterating the originating message below:

Hello,

I'm looking for some help on fixing PR48030<https://bugs.llvm.org/show_bug.cgi?id=48030>, which is a fairly serious issue affecting our licensees.
A reproducible is available in the bug report, but in a nutshell, what happens is the following:

2 translation units A and B have definitions for an implicitly instantiated file-level
TLS (thread local storage) variable, both generating the same global initializer function as part
of the same comdat group as one would expect. TU B also generates a wrapper for accessing the TLS variable,
but TU A does not, because it is not needed there.
The wrapper in TU B calls the initializer function to ensure initialization of the TLS variable. It does
so through an alias of the initializer. At linktime, however, the call to the alias (weak linkage) gets fixed
up to 0 when TU A first appears on the link line, b/c the linker picks the comdat group from TU A, whereas the
relocation against the alias is fixed up against the discarded initializer from TU B.

I've made some feeble attempts to play around with the linkages of the entities involved, but the only
way I have come up with is to eliminate the alias and call the initializer directly from the wrapper.
This breaks other things, however, so it's not an option.

Any help would be appreciated.
Wolfgang Pieb
SN Systems/Sony Computer Entertainment


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210304/fa060305/attachment.html>