Oops, here is the patch.

On Sat, Aug 5, 2017 at 10:14 AM, David Grayson <davidegray...@gmail.com> wrote:
> 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
>>
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 07a18408..5b759fe3 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -40,6 +40,15 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
 extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
 extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
 
+__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;
+__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;
+
 /* TLS initialization hook.  */
 extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;
 
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index ae37e0fe..d3b80bbc 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -60,6 +60,15 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
 extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
 extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
 
+__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;
+__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;
+
 /* TLS initialization hook.  */
 extern const PIMAGE_TLS_CALLBACK __dyn_tls_init_callback;
 
diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c
index fc0e3500..134876c4 100644
--- a/mingw-w64-crt/crt/gccmain.c
+++ b/mingw-w64-crt/crt/gccmain.c
@@ -9,8 +9,8 @@
 #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__[];
 
 void __do_global_dtors (void);
 void __do_global_ctors (void);
@@ -19,7 +19,7 @@ void __main (void);
 void
 __do_global_dtors (void)
 {
-  static func_ptr *p = __DTOR_LIST__ + 1;
+  static func_ptr *p = __MINGW_DTOR_LIST__ + 1;
 
   while (*p)
     {
@@ -31,17 +31,14 @@ __do_global_dtors (void)
 void
 __do_global_ctors (void)
 {
-  unsigned long nptrs = (unsigned long) (ptrdiff_t) __CTOR_LIST__[0];
+  unsigned long nptrs;
   unsigned long i;
 
-  if (nptrs == (unsigned long) -1)
-    {
-      for (nptrs = 0; __CTOR_LIST__[nptrs + 1] != 0; nptrs++);
-    }
+  for (nptrs = 0; __MINGW_CTOR_LIST__[nptrs + 1] != 0; nptrs++);
 
   for (i = nptrs; i >= 1; i--)
     {
-      __CTOR_LIST__[i] ();
+      __MINGW_CTOR_LIST__[i] ();
     }
 
   atexit (__do_global_dtors);
------------------------------------------------------------------------------
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

Reply via email to