I think Martell's last patch would have worked but it's not as safe as
I would like it to be. I think the constructor and destructor lists
should not be defined in gccmain.c where they are used, because then
the compiler optimizer might start to get smart and stop optimizing
things in a bad way. The kind of pointer arithmetic we're doing would
be undefined behavior since we're intentionally getting a pointer to
an object and then reading past the end of that object.
Also, I think we should add new symbols so there is no potential for a
clash with the symbols defined by the linker script in binutils.
So, attached to this email is a patch that worked for me (I was able
to compile and run a Qt Widgets application). I'm not entirely sure
it would be a good patch to use though, since I'm not sure how GCC
picks names for its global constructor and destructor sections, and
how it sorts those names, so I'm not sure that the symbols we are
defining would really be in the right place.
--David Grayson
On Sat, Aug 5, 2017 at 4:45 AM, Martell Malone <martellmal...@gmail.com> wrote:
> Hey David,
>
>
>> 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.
>
>
> It applies cleanly to HEAD.
> I changed to so that all it does is SORT the ctors and dtors sections.
> Someone would have to confirm though.
>
> Maybe crtexe.c is not linked into shared libraries since they are not EXEs.
>
> That is exactly what happened there crtdll.c is used instead.
> Here is an updated patch which also applies to crtdll.c
>
> Also the only reason I am not putting it into gccmain.c is because I am
> having problems with creating it and then using is as a array.
> If someone is able to do that it would be much better.
>
> Transforming
> __attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
> *)))) const func_ptr __CTOR_LIST__[] = {(void *) -1};
> into
> func_ptr __CTOR_LIST__[]
> is being problematic within the one source.
>
> I'd gladly take direction from someone here on that if they have any ideas.
>
> Best,
> Martell
>
> On Sat, Aug 5, 2017 at 5:53 AM, David Grayson <davidegray...@gmail.com>
> wrote:
>
>> With your latest two patches, the toolchain compiles but I get an
>> error when building a shared library:
>>
>> /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-
>> w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_a-gccmain.o):
>> In function `_do_global_dtors':
>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/
>> build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-
>> w64-crt/crt/gccmain.c:25:
>> undefined reference to `__DTOR_END__'
>> /tmp/nix-build-mingw-w64-2017-08-03-i686-w64-mingw32.drv-0/
>> build_crt_and_headers/mingw-w64-crt/../../mingw-w64/mingw-
>> w64-crt/crt/gccmain.c:25:
>> undefined reference to `__DTOR_END__'
>> /nix/store/k481dhv5hivggnjyb9rs95fz1k6ylhjz-mingw-w64-2017-08-03-i686-
>> w64-mingw32/lib/../lib/libmingw32.a(lib32_libmingw32_
>> a-gccmain.o):gccmain.c:(.data+0x0):
>> undefined reference to `__CTOR_END__'
>>
>> Maybe crtexe.c is not linked into shared libraries since they are not EXEs.
>>
>> --David
>>
>> On Fri, Aug 4, 2017 at 6:12 PM, David Grayson <davidegray...@gmail.com>
>> wrote:
>> > 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 <davidegray...@gmail.com>
>> 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 <martellmal...@gmail.com>
>> 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 <
>> davidegray...@gmail.com>
>> >>> 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/s27xhxkbq4qxadhzpn5vh5kkffnfvi
>> zy-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/s27xhxkbq4qxadhzpn5vh5kkffnfvi
>> zy-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 <
>> martellmal...@gmail.com>
>> >>>> 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ö <mar...@martin.st>
>> wrote:
>> >>>> >
>> >>>> >> On Fri, 4 Aug 2017, Ruben Van Boxem wrote:
>> >>>> >>
>> >>>> >> Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" <
>> >>>> martellmal...@gmail.com
>> >>>> >>> >:
>> >>>> >>>
>> >>>> >>> 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
>> >>>> >> Mingw-w64-public@lists.sourceforge.net
>> >>>> >> 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
>> >>>> > Mingw-w64-public@lists.sourceforge.net
>> >>>> > 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
>> >>>> Mingw-w64-public@lists.sourceforge.net
>> >>>> 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
>> >>> Mingw-w64-public@lists.sourceforge.net
>> >>> 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
>> Mingw-w64-public@lists.sourceforge.net
>> 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
> Mingw-w64-public@lists.sourceforge.net
> 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
