Looking for help with static initialization of thread locals (PR48030)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Looking for help with static initialization of thread locals (PR48030)

Manas 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, 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

 

 


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev