On Jun 17 11:35, Jeremy Drake via Cygwin-patches wrote: > On Tue, 17 Jun 2025, Corinna Vinschen wrote: > > > On Jun 17 10:21, Jeremy Drake via Cygwin-patches wrote: > > > The pthread macros were previously casts of integers to pointers, which > > > would always be full absolute pointers. This change is making them actual > > > symbols which the linker fills in with absolute addresses. This would be > > > out of range of a 32-bit rip-relative relocation in cases where the image > > > base is >4GB. > > > > > > This is really gross, as I said, but was the only way I came up with to > > > make them satisfy constinit's restrictions in clang (and the standard, it > > > seems GCC allows things that are explicitly disallowed by the standard). > > > > Ok, but then I'm still puzzled about the code. > > > > First of all, shouldn't the new symbols get exported explicitly via > > cygwin.din? > > No, as i said they can't be used from the DLL anyway. I included them in > libcygwin.a (LIB_FILES) for external users, and in the dll (DLL_FILES) for > internal uses. > > > Second, I'm puzzeling over the #if expression (cut for a simple example): > > > > #if !defined(__INSIDE_CYGWIN__) || !defined(__cplusplus) > > /* use symbols */ > > #else > > /* use const int cast to pointer */ > > #endif > > > > So this is a problem in terms of constinit. Constinit is a C++20 > > expression. But the condition will only define PTHREAD_... using the > > symbols if this is either outside Cygwin, or if the Cygwin code is NOT > > C++. > > > > The usage inside Cygwin seems upside down to me. Shouldn't it use the > > symbols in C++ code but not in plain C? Or am I misunderstanding the > > condition entirely? > > The reason I kept the old cast-to-pointer path inside Cygwin C++ code is > that that case triggered the "relocation truncated to fit" error. Also, > that matches the condition inside sys/_pthreadtypes.h to cast to a class > pointer instead of a struct pointer. > > > > > Somewhat surprising to me is that clang also disallows using the address > > > of a dllimported extern variable in constinit, so we couldn't even > > > dllexport "magic" objects from the DLL whose addresses could be compared > > > against instead of (pthread_mutex_t)19 and such. > > > > We also have the choice to export the symbols from libcygwin.a, see the > > files in LIB_FILES in Makefile.am. Would that allow clang to use them > > in constinit? Theoretically we could also define them in crt0.o, but > > this looks too much like just another hack... > > Yes, that's what I did...
So it all boils down to me not reading your patch correctly. D'oh. And no, I don't see a better way to avoid the original constinit problem, so your patch is GTG. 3.6 branch, too, I guess. Thanks, Corinna
