I thought my last email explained it pretty well. The optimizer can
do any kind of transformation it wants on the code as long as it
doesn't change the behavior of well-defined programs. You seem to be
stuck on the "__used__" attribute but that's not relevant to my
argument.
--David
On Sun, Aug 6, 2017 at 8:08 AM, Martell Malone <martellmal...@gmail.com> wrote:
>>
>> What I meant is that if GCC's optimizer ever figures out that we are
>> comparing pointers that came from two different memory objects, it
>> would know we are doing undefined behavior and would have a license to
>> do whatever it wants, including removing that code. The way the loop
>> is written right now is probably safer than anything that uses a
>> symbol at the end of the constructors.
>
> I still do not see how this is relevant, we are specifying a used symbols
> on specific section names.
> The compiler has no recourse for optimising this out.
> It is the linker that will organise the sections and fill in the branch
> offsets.
> Even with LTO this would not fail.
>
> On Sat, Aug 5, 2017 at 8:44 PM, David Grayson <davidegray...@gmail.com>
> wrote:
>
>> What I meant is that if GCC's optimizer ever figures out that we are
>> comparing pointers that came from two different memory objects, it
>> would know we are doing undefined behavior and would have a license to
>> do whatever it wants, including removing that code. The way the loop
>> is written right now is probably safer than anything that uses a
>> symbol at the end of the constructors.
>>
>> --David
>>
>> On Sat, Aug 5, 2017 at 11:52 AM, Martell Malone <martellmal...@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.
>> >
>> > That won't happen, this is what the attribute __used__ is for.
>> > The issue I have is about casting in a clean way.
>> > I also don't see the point in iterating through a list to get to the end
>> > and then navigating back through it again if you have a pointer to the
>> last
>> > element.
>> >
>> >>
>> >> 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.
>> >
>> > As I said in a previous email this would be one way to solve it yes.
>> > Here is what I said
>> >> This would mean that programs linked with LD would have an extra 2
>> > pointers in the table but it should be fine otherwise.
>> > I would be cleaner and better to change the linker script though.
>> >
>> > On Sat, Aug 5, 2017 at 6:15 PM, David Grayson <davidegray...@gmail.com>
>> > wrote:
>> >
>> >> 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/k481dhv5hivggnjyb9rs95fz1k6ylh
>> jz-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/k481dhv5hivggnjyb9rs95fz1k6ylh
>> jz-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
>> >>
>> >>
>> > ------------------------------------------------------------
>> ------------------
>> > 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
