mstorsjo
Joined 4 years ago
Karma
12
Submissions
6
Member since
Dec 19
Recent submissions
Comment · 3 years ago
Comment · 4 years ago
Oh, I forgot to add; these days, msys2 have got a number of extra package repos. They have one, "CLANG64", which has got Clang/lld as the default compiler (just like in llvm-mingw) and with all packages built that way. And there, it defaults to native TLS too. Depending on your use case, this might be easier to take for a spin than llvm-mingw.
Comment · 4 years ago
Clang (and lld) do support native TLS, and mingw-w64 does have the things that are needed. I think binutils also might have what's needed too, but AFAIK the thing that's missing is support for it in GCC.
Actually, (upstream) Clang defaults to native TLS instead of emulated TLS. In MSYS2, Clang is overridden to use emulated TLS by deafult to interoperate better with GCC built code and libstdc++ though.
The toolchain I maintain, https://github.com/mstorsjo/llvm-mingw, defaults to native TLS throughout.
Comment · 4 years ago
Regarding error reporting - yeah, it's super non obvious when that happens. See the sibling post I made; I've added error reporting for that case now (2 months ago, so not in any released version yet).
Comment · 4 years ago
A couple more details:
> The pseudo reloc code does not output any errors when the address overflows; would probably be worth a pull request
I actually did this, to make it error out cleanly instead of having to debug this very non-obvious issue, quite recently: https://github.com/mingw-w64/mingw-w64/commit/ca35236d9799af...
(It's not in any stable release yet, but MSYS2 might be packaging recent git snapshots that could contain it.)
> Check to see if your MinGW program has unexpected imports to kernel32.VirtualProtect!
The runtime pseudo relocation fixing code ends up linked into your executables even if the executable doesn't use any runtime pseudo relocations - so essentially all MinGW programs will end up importing this function. That doesn't mean it does get called though.
I actually did look into fixing it, to make it only be pulled in when something needs it. It would need changes both to the linkers (binutils ld.bfd and lld) and mingw-w64-crt. I do have WIP patches for this for lld and mingw-w64-crt, but I'm not familiar with with the ld.bfd internals to take on fixing that. Plus that changing it would break older versions of the linker, so it would require quite a bit of a transition phase.
Comment · 4 years ago
In general, this doesn't work by accident. In practice, whenever calling a function from a different DLL, normally a thunk is inserted (if it isn't marked dllimport), and when referencing a variable that might reside in a different DLL (and be autoimported), its address is read indirectly via a full 64 bit pointer.
When linking to a function "func" in another DLL, the import library normally provides two symbols, "func" which is a thunk which allows it to be called from anywhere, and "__imp_func" which is the IAT entry (containing a full 64 bit address). If the caller called it via a dllimport marked declaration, it's using "__imp_func", otherwise it uses "func" and ends up jumping via a thunk.
In some cases, when mingw-w64 wants to override importing certain functions (by providing a statically linked version of it instead), the functions are marked "DATA" in the def file (which is used for generating the import libraries). Then the thunk is left out and only the "__imp_func" symbol is left. If you hit a situation where you didn't end up linking the intended replacement function, then it's possible to hit this situation where you autoimport something that only works if it's loaded close enough. (In hindsight, it might have been even better to comment out those functions entirely from the import libraries.)
If you do hit this issue again (or if you remember exactly how to reproduce it), then plese do file a bug somewhere so we can look into it.
But in general, mingw-w64 linked binaries, even including ones using the autoimport facility and runtime pseudo relocations, should work even if they are loaded far apart from each other.
Edit: Oh, I see this does have SVE2 as well - that's great!
The ARM ARM is quite heavy to browse; for baseline NEON, I've used the "ARMv8 Instruction Set Overview" [1] which comes in a a neat 115 pages, which is great for easy browsing and finding what's available. But for anything newer than the baseline, one pretty much has to refer to the ARM ARM right now.
[1] It used to be available from ARM themselves, but I can't seem to find it these days. I've found one copy online at https://www.cs.princeton.edu/courses/archive/spr19/cos217/re... though.