Page MenuHomePhabricator

[clang] [MinGW] Don't mark emutls variables as DSO local

Authored by mstorsjo on May 22 2021, 3:54 PM.



These actually can be automatically imported from another DLL. (This
works properly as long as the actual implementation of emutls is
linked dynamically from e.g. libgcc; if the implementation comes from
compiler-rt or a statically linked libgcc, it doesn't work as intended.)

This fixes PR50146 and
(fixing calling std::call_once in a dynamically linked libstdc++);
since f73183958482602c4588b0f4a1c3a096e7542947 the dso_local attribute
on the TLS variable affected the actual generated code for accessing
the emutls variable.

The dso_local attribute on the emutls variable made those accesses to
use 32 bit relative addressing in code, which requires runtime pseudo
relocations in the text section, and breaks entirely if the actual
other variable ends up loaded too far away in the virtual address

Diff Detail

Event Timeline

mstorsjo requested review of this revision.May 22 2021, 3:54 PM
mstorsjo created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptMay 22 2021, 3:54 PM
mati865 accepted this revision.May 22 2021, 4:56 PM

Wow, I haven't expected that.

This revision is now accepted and ready to land.May 22 2021, 4:56 PM

@rnk Does this seem ok to you too?


I guess that it’d be good to point out the reverse too, that native tls variables on windows can’t be dllimported.

rnk accepted this revision.Thu, May 27, 1:34 PM


This revision was automatically updated to reflect the committed changes.