llvm dev - Mar 2021 - Looking for help with static initialization of thread locals (PR48030)

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/llvm-dev/attachments/20210304/fa060305/attachment.html>