On Fri, 1 Dec 2023, Antonin Décimo wrote:
We can use `#pragma section` and `__declspec(allocate("xxx"))` instead.Umm, this doesn't seem to work for me. With your example code below, with foo_init renamed into main(), I don't get any working TLS callbacks, on neither x86 nor x64, and linking produces the following warning: LIBCMT.lib(tlssup.obj) : warning LNK4078: multiple '.CRT' sections found with different attributes (40400040) LIBCMT.lib(initializers.obj) : warning LNK4254: section '.CRT' (50000040) merged into '.rdata' (40000040) with different attributesMy bad, the warning disappears if the "shared" attribute is not used. If I remove it, all the test cases behave correctly. It seems that if we use `const_seg`, we don't need the `__declspec(allocate(".CRT$XLF"))` expanded by `WINPTHREADS_ATTRIBUTE(WINPTHREADS_SECTION(".CRT$XLF"))` Should I keep the macros only if __GNUC__ is defined? To me, using `const_seg` feels a little bit less like magic than using `section`.
Actually, I feel the other way around. With #pragma section(), we just declare that we might add things to this section somewhere later, and then we add this specific variable to it with __declspec(allocate()) - which maps nicely to WINPTHREADS_ATTRIBUTE(WINPTHREADS_SECTION(...)). This requires fewer ifdefs (only one for #pragma section, which can be merged with the ones for other pragmas for MSVC).
Compared with the existing code, it only requires tweaking the one #pragma section line, right? One might want to remove the #pragma data_seg() as I'm not sure why that's needed at all.
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
