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