Page MenuHomePhabricator

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

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

Details

Summary

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 https://github.com/msys2/MINGW-packages/issues/8706
(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
space.

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?

clang/lib/CodeGen/CodeGenModule.cpp
992

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

lgtm

This revision was automatically updated to reflect the committed changes.