Oh, I mean that I got the patch to apply, but I don't know if it really *works*; the toolchain is still building at this time. --David
On Fri, Aug 4, 2017 at 6:11 PM, David Grayson <[email protected]> wrote: > Your binutils patch did not apply cleanly to binutils-2.27 but I got > it to work. It looks pretty dangerous to me because you removed the > lines for keeping the .dtors, .dtor, .ctors, and .ctor sections. And > you're using .ctors and .dtors in your other patch, and other code > might use them too I suppose. > > --David > > On Fri, Aug 4, 2017 at 5:39 PM, Martell Malone <[email protected]> > wrote: >> Hey David, >> >> This could be caused by gcc including it's own crtbegin.o and crtend.o >> I managed to install a toolchain with brew and I swapped out gcc's and >> mingw-w64's crtbegin and crtend. >> Everything seems to work here as intended. >> Attached is an updated patch that avoids crtbegin and crtend that should >> work along with a patch for binutils. >> >> Kai could you give some input on the binutils patch. >> On a side note while we are at this we should change __image_base__ >> to ___ImageBase and __ImageBase on x86 and x64 respectively. >> Best, >> Martell >> >> On Sat, Aug 5, 2017 at 12:20 AM, David Grayson <[email protected]> >> wrote: >> >>> Martell: >>> >>> My setup ( https://github.com/DavidEGrayson/nixcrpkgs ) makes it quite >>> easy to try random patches and make sure that GCC can still be >>> bootstrapped and that I can build non-trivial applications. I tried >>> your patch (after fixing the linebreaks added by GMail) but >>> unfortunately it doesn't work. >>> >>> When building the final GCC, I got this error: >>> >>> ~~~~ >>> checking for ld that supports -Wl,--gc-sections... configure: error: >>> Link tests are not allowed after GCC_NO_EXECUTABLES. >>> make[1]: *** [Makefile:9917: configure-target-libstdc++-v3] Error 1 >>> make[1]: Leaving directory >>> '/tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build' >>> make: *** [Makefile:878: all] Error 2 >>> ~~~~ >>> >>> I've experienced this before and it just means something went wrong >>> earlier in the configure script, and GCC, in its infinite wisdom, >>> decided that it was targeting a system that does not support >>> executables (?). Digging through the config.log for libstdc++-v3, I >>> found a suspicious error: >>> >>> ~~~~ >>> configure:3952: $? = 1 >>> configure:3968: >>> /tmp/nix-build-gcc-6.3.0-i686-w64-mingw32.drv-0/build/./gcc/xgcc >>> -B/tmp/nix-build-gcc-6.3.0-i686-w64-m >>> ingw32.drv-0/build/./gcc/ >>> -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>> i686-w64-mingw32/i686-w64-mingw32/li >>> b -L/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>> i686-w64-mingw32/mingw/lib >>> -isystem /nix/store/s27xhxkbq4qxa >>> dhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw32/i686-w64-mingw32/include >>> -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkff >>> nfvizy-gcc-6.3.0-i686-w64-mingw32/mingw/include >>> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686-w64-mingw >>> 32/i686-w64-mingw32/bin/ >>> -B/nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0- >>> i686-w64-mingw32/i686-w64-mingw32/lib >>> / -isystem /nix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686- >>> w64-mingw32/i686-w64-mingw32/include >>> -isystem /n >>> ix/store/s27xhxkbq4qxadhzpn5vh5kkffnfvizy-gcc-6.3.0-i686- >>> w64-mingw32/i686-w64-mingw32/sys-include >>> -o conftest -g -O >>> 2 conftest.c >&5 >>> /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017- >>> 08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin >>> gw32_a-gccmain.o): In function `_do_global_dtors': >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_LIST__' >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:25: undefined reference to `__MINGW_DTOR_END__' >>> /nix/store/262jyalfa9jz5say3782fcdh2zw4n301-mingw-w64-2017- >>> 08-03-i686-w64-mingw32/lib/../lib/libmingw32.a(lib32_libmin >>> gw32_a-gccmain.o): In function `_do_global_ctors': >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_END__' >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__' >>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/b >>> uild_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-w >>> 64-crt/crt/gccmain.c:35: undefined reference to `__MINGW_CTOR_LIST__' >>> ~~~~ >>> >>> I'm not sure why those things would be undefined, but the order of >>> linking of these libraries does matter and perhaps they are being >>> linked in the wrong order. >>> >>> --David >>> >>> On Fri, Aug 4, 2017 at 12:50 PM, Martell Malone <[email protected]> >>> wrote: >>> > Okay lets just solve this. >>> > I believe the following should work for both clang and gcc >>> > I added a test case at the bottom also. >>> > >>> > diff --git a/mingw-w64-crt/crt/crtbegin.c b/mingw-w64-crt/crt/crtbegin.c >>> > index 39c0d856..1672f7b9 100644 >>> > --- a/mingw-w64-crt/crt/crtbegin.c >>> > +++ b/mingw-w64-crt/crt/crtbegin.c >>> > @@ -4,3 +4,5 @@ >>> > * No warranty is given; refer to the file DISCLAIMER.PD within this >>> > package. >>> > */ >>> > >>> > +__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void >>> > *)))) const void * __MINGW_CTOR_LIST__ = (void *) -1; >>> > +__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void >>> > *)))) const void * __MINGW_DTOR_LIST__ = (void *) -1; >>> > diff --git a/mingw-w64-crt/crt/crtend.c b/mingw-w64-crt/crt/crtend.c >>> > index 39c0d856..d1b6b426 100644 >>> > --- a/mingw-w64-crt/crt/crtend.c >>> > +++ b/mingw-w64-crt/crt/crtend.c >>> > @@ -4,3 +4,5 @@ >>> > * No warranty is given; refer to the file DISCLAIMER.PD within this >>> > package. >>> > */ >>> > >>> > +__attribute__ (( __section__ (".ctors$zzz"), __used__ , >>> > aligned(sizeof(void *)))) const void * __MINGW_CTOR_END__ = (void *) 0; >>> > +__attribute__ (( __section__ (".dtors$zzz"), __used__ , >>> > aligned(sizeof(void *)))) const void * __MINGW_DTOR_END__ = (void *) 0; >>> > diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c >>> > index fc0e3500..7401e812 100644 >>> > --- a/mingw-w64-crt/crt/gccmain.c >>> > +++ b/mingw-w64-crt/crt/gccmain.c >>> > @@ -9,8 +9,10 @@ >>> > #include <setjmp.h> >>> > >>> > typedef void (*func_ptr) (void); >>> > -extern func_ptr __CTOR_LIST__[]; >>> > -extern func_ptr __DTOR_LIST__[]; >>> > +extern func_ptr __MINGW_CTOR_LIST__[]; >>> > +extern func_ptr __MINGW_DTOR_LIST__[]; >>> > +extern func_ptr __MINGW_CTOR_END__[]; >>> > +extern func_ptr __MINGW_DTOR_END__[]; >>> > >>> > void __do_global_dtors (void); >>> > void __do_global_ctors (void); >>> > @@ -19,31 +21,21 @@ void __main (void); >>> > void >>> > __do_global_dtors (void) >>> > { >>> > - static func_ptr *p = __DTOR_LIST__ + 1; >>> > - >>> > - while (*p) >>> > - { >>> > - (*(p)) (); >>> > + func_ptr *p = __MINGW_DTOR_LIST__ + 1; >>> > + while(p < __MINGW_DTOR_END__) { >>> > + if (*p) (*(p)) (); >>> > p++; >>> > - } >>> > + } >>> > } >>> > >>> > void >>> > __do_global_ctors (void) >>> > { >>> > - unsigned long nptrs = (unsigned long) (ptrdiff_t) __CTOR_LIST__[0]; >>> > - unsigned long i; >>> > - >>> > - if (nptrs == (unsigned long) -1) >>> > - { >>> > - for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++); >>> > - } >>> > - >>> > - for (i = nptrs; i >= 1; i--) >>> > - { >>> > - __CTOR_LIST__[i] (); >>> > - } >>> > - >>> > + func_ptr *p = __MINGW_CTOR_END__ - 1; >>> > + while(p > __MINGW_CTOR_LIST__) { >>> > + if (*p) (*(p)) (); >>> > + p--; >>> > + } >>> > atexit (__do_global_dtors); >>> > } >>> > >>> > Attached also is a testcase for ctors and dtors >>> > >>> > #include <stdio.h> >>> > >>> > void ctorTest(void) __attribute__ ((constructor)); >>> > void dtorTest(void) __attribute__ ((destructor)); >>> > >>> > void ctorTest(void) { >>> > printf ("ctor before main\n"); >>> > } >>> > >>> > void dtorTest(void) { >>> > printf ("dtor after main\n"); >>> > } >>> > >>> > int main() >>> > { >>> > printf ("hello\n"); >>> > return 0; >>> > } >>> > >>> > I get the following output with clang. >>> > >>> > ctor before main >>> > hello >>> > dtor after main >>> > >>> > Can someone test this on a gcc toolchain and confirm. >>> > I haven't built a mingw-w64 with gcc and binutils in so long. >>> > >>> > Best, >>> > Martell >>> > >>> > On Fri, Aug 4, 2017 at 7:53 PM, Martin Storsjö <[email protected]> wrote: >>> > >>> >> On Fri, 4 Aug 2017, Ruben Van Boxem wrote: >>> >> >>> >> Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" < >>> [email protected] >>> >>> >: >>> >>> >>> >>> I for one would like to be able to use one crt with both Clang and >>> GCC. No >>> >>> use in duplicating 99% of the code for that one little bit of startup >>> code >>> >>> that needs to be different. Perhaps ldd or Clang needs to be taught to >>> >>> link >>> >>> a different startup object, but that should be trivial to accomplish! >>> >>> >>> >> >>> >> Being able to use the same build of mingw with either compiler (or more >>> >> practically, linker) would be ideal yeah. In addition to the constructor >>> >> handling, there's also the issue that lld fails to link to import >>> libraries >>> >> created by GNU dlltool. >>> >> >>> >> >>> >> Initial brain dump of what I've discovered on the matter so far: >>> >> >>> >> MSVC link.exe also used to fail linking to such import libraries (with >>> >> slightly different symptoms), prior to MSVC 2012 where it started >>> working. >>> >> (Not sure if this was an intentional fix from their side or not.) >>> >> >>> >> With link.exe, the output binary does link to the DLL, but doesn't >>> >> actually import the functions. With lld, the output binary doesn't >>> actually >>> >> end up linking to the DLL at all, iirc. >>> >> >>> >> In lld, in LinkerDriver::addArchiveBuffer, the "proper" import >>> libraries >>> >> (from the windows SDK, and the ones produced by llvm-dlltool) get >>> >> identified as coff_import_library and get treated differently, while the >>> >> GNU dlltool ones just are treated as any normal static library-. >>> >> >>> >> >>> >> // 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 >>> >>> ------------------------------------------------------------ >>> ------------------ >>> 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 >> ------------------------------------------------------------------------------ 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
