- User Since
- Jul 25 2016, 12:54 PM (72 w, 6 h)
Updated to pass the flag through on these architectures.
Sat, Dec 9
Mon, Dec 4
FWIW, the commit message here ended up misleading - native TLS does work on mingw-w64 as well (with clang+lld), after a minor tweak to the crt wrapping in mingw-w64.
Sat, Dec 2
Wed, Nov 29
Tue, Nov 28
Mon, Nov 27
Added zero padding for ELF as well, rewrote the zero padding in a more idiomatic way, applied Rui's style suggestion.
Sun, Nov 26
Added a comment in the source to clarify that this is for MinGW.
I noticed that GCC actually does zero pad these, and GNU ld expects them zero padded, so this simplifies this patch quite significantly. The .ctors$zzz part is only used in the llvm/lld specific parts of mingw-w64, and can be replaced with .ctors.99999 or something similar once this goes in, to avoid the need for the special sorting of them.
I noticed that the .ctors.1234 numerical suffixes are zero padded by GCC when targeting MinGW, updated this patch accordingly and expanded the test to showcase it.
Fri, Nov 24
Added comments, removed redundant checking for periods (replaced with asserts), removed the redundant StringRef references.
Thu, Nov 23
Wed, Nov 22
Looks really good to me now! @rnk?
LGTM, thanks for updating it!
Tue, Nov 21
No objection from me about committing this now, although I have some minor comments (that possibly can be taken care of without reposting and re-reviewing). Still ok with @rnk?
... so in general I wouldn't mind doing a change like this, but I'd like to make it consistent on ARM, i386 and x86_64 at the same time in that case, instead of just changing aarch64.
WIN32 and WIN64 are not real definitions they are typically defined by the system headers, _WIN32 and _WIN64 are the compiler definitions.
Mon, Nov 20
In order to make this work with MinGW (more or less), I had to change the _LIBCPP_MSVCRT into _LIBCPP_MSVCRT_LIKE both in include/__locale and in include/__config (where _LIBCPP_LOCALE__L_EXTENSIONS is defined). Normal mingw that uses msvcrt.dll doesn't have per-thread locales so it won't really work in any case (but I think it does define some sort of dummy functions that at least will allow it to build). Nowadays, mingw can be built to target ucrtbase.dll as well though, and there it should be possible to make it work just like for MSVC although it might need some patches.
Sun, Nov 19
Fri, Nov 17
I presume that this only works as long as you build libunwind and libcxxabi together in a single build instead of building them standalone? (Or put another way; when building llvm+clang+lld on linux, for linux, intended to be used as cross compiler for windows - is there any way to build libunwind+libcxxabi+libcxx within the same source tree for i686,x86_64,arm,arm64 windows/mingw?)
D39533 was committed now, so before committing, make sure that the __ARM_DWARF_EH__ (that was added in that commit) only gets set while dwarf is enabled (which now is the default for mingw/arm but not msvc/arm).
Thu, Nov 16
@ruiu Any comments on this version of the patch?
Wed, Nov 15
Identified the actual root cause, improved the related code further by checking for specific types of Defined symbols, added a test.
Always truncate the names of sections that will be mapped at runtime, as suggested by @rnk.