Hello. Bellow my signature is a copy of the explanation I sent to the list about why ca451a7 should be reverted.
The issue is that different objects are adding constructor pointers to a special section for it, and the CRT need to reliably find the beginning of that section. The CRT uses special symbols defined by the linker script, __CTOR_LIST and __DTOR_LIST__. But Martell says clang cannot understand linker scripts. Does clang produce any special symbols at the beginning or end of sections? Is there a way to make it do that? That would be handy. Martell's code as presented at the beginning of this thread could work too, and putting it in a separate object file just for clang seems like a good idea. I think Martell's patch is relying on sections to be sorted in alphabetical order. --David Grayson -------------------------- Hello. Commit ca451a7a45d4876065edc6755f8aab8095914b04 caused issue #1104 in MSYS2, where basic C++ programs stopped working, probably because constructors were not called: https://github.com/Alexpux/MINGW-packages/issues/1104 If you compile a simple C++ hello world program, you can run the following command on it to see where the relevant symbols are getting placed: objdump -t prog.exe | egrep 'TOR_LIST|dtors|ctors' On my machine, using a 64-bit toolchain, I'm seeing that __CTOR_LIST__ is at 0x1e60 while __MINGW_CTOR_LIST__ is at 0x1e70. That is a difference of 16 bytes, so there are two constructors that wouldn't get run if you choose to use __MINGW_CTOR_LIST__ as the starting point for your loop that calls all the constructors. There is also a discrepancy for the destructors. The symbols __CTOR_LIST__ and __DTOR_LIST__ are actually defined in the linker script. My evidence for that is that if I compile a C++ program with "-Wl,-verbose", the default linker script is printed, and it has these lines to define __CTOR_LIST__ and __DTOR_LIST__ properly: . = ALIGN(8); ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; LONG (-1); LONG (-1);*(.ctors); *(.ctor); *(SORT(.ctors.*)); LONG (0); LONG (0); ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; LONG (-1); LONG (-1); *(.dtors); *(.dtor); *(SORT(.dtors.*)); LONG (0); LONG (0); *(.fini) The statement "___CTOR_LIST__ = ." tells the linker to define a symbol named ___CTOR_LIST__ at the current location (.). Then it puts some padding data, and then it puts all the constructors, and then it puts a null terminator. In contrast, the newly-introduced symbols __MINGW_CTOR_LIST__ and __MINGW_DTOR_LIST__ do not work properly because they were not placed in the right locations using a linker script. They were just defined as static variables in a particular section. Martell, I gather that you were working on some clang-based toolchain and you had trouble because __CTOR_LIST__ and __DTOR_LIST__ were not defined. Could you solve your issue by defining them in your linker script or something? I think commit ca451a7a45d4876065edc6755f8aab8095914b04 can be reverted. --David On Fri, Aug 4, 2017 at 11:34 AM, Martin Storsjö <[email protected]> wrote: > On Thu, 3 Aug 2017, Martell Malone wrote: > >> Hey Martin, >> >> Glad to see you following up on my various LLVM adventures :) >> >> From what I remember the initialization is done in >> mingw-w64/crt/gccmain.c. >> I believe it may be possible to add this code and not make is clang >> specific. >> >> Before the iteration loop check in __do_global_ctors >> and __do_global_dtors check if nptrs+1 is equal to -1 and if so just bump >> the counter and continue. >> This would mean that programs linked with LD would have an extra 2 >> pointers >> in the table but it should be fine otherwise. >> >> Not sure how others would feel about this though. > > > Without having looked closer into this yet, I guess this is kinda what you > attempted in ca451a7a45d4876065edc6755f8aab8095914b04, which later was > reverted in 5981c0281b1f65b8f9b38b13f504f8af3f6ff209? So I guess that would > be a decent starting point, but trying to fix whatever that attempt broke? > > // Martin > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Mingw-w64-public mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
