Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
W dniu 31.08.2018 o 14:38, Martin Storsjö pisze: >> On Aug 31, 2018, at 14:05, Mateusz wrote: >> >> W dniu 31.08.2018 o 12:17, Martin Storsjö pisze: >>> On Aug 31, 2018, at 12:51, Mateusz wrote: W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >> On Aug 29, 2018, at 18:44, Martell Malone >> wrote: >> >> LGTM. > > Pushed this version. > > // Martin It's not working for me (when I build gcc on ubuntu). Could we revert this patch? >>> >>> Maybe, but first I'd like to know more about what doesn't work for you. >>> What step fails for you? >>> >>> What does configure say about "Checking whether the linker provides >>> __CTOR_LIST__"? Do you use specifically binutils 2.30? Can you provide the >>> config.log from that run? >>> >>> // Martin >> >> binutils 2.31.1, config.log + config.h attached (from building gcc cross >> compiler on ubuntu) > > Thanks - I managed to reproduce the issue by testing bootstrapping with the > same version of GCC (8.2) as you; this is an issue that doesn’t reproduce > with a versions older. The issue was we tried to trick autoconf into running > linking tests even though autoconf had earlier concluded that linking doesn’t > work. > > I pushed a fix for this; instead of using the autoconf linker test machinery, > just manually run the specific command we wanted to test. Hopefully this now > works for everyone, otherwise we’ll have to revert this test again. > > // Martin Now it is OK. Thanks! -- 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
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
> On Aug 31, 2018, at 14:05, Mateusz wrote: > > W dniu 31.08.2018 o 12:17, Martin Storsjö pisze: >> On Aug 31, 2018, at 12:51, Mateusz wrote: >>> >>> W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: > On Aug 29, 2018, at 18:44, Martell Malone wrote: > > LGTM. Pushed this version. // Martin >>> >>> It's not working for me (when I build gcc on ubuntu). >>> Could we revert this patch? >> >> Maybe, but first I'd like to know more about what doesn't work for you. What >> step fails for you? >> >> What does configure say about "Checking whether the linker provides >> __CTOR_LIST__"? Do you use specifically binutils 2.30? Can you provide the >> config.log from that run? >> >> // Martin > > binutils 2.31.1, config.log + config.h attached (from building gcc cross > compiler on ubuntu) Thanks - I managed to reproduce the issue by testing bootstrapping with the same version of GCC (8.2) as you; this is an issue that doesn’t reproduce with a versions older. The issue was we tried to trick autoconf into running linking tests even though autoconf had earlier concluded that linking doesn’t work. I pushed a fix for this; instead of using the autoconf linker test machinery, just manually run the specific command we wanted to test. Hopefully this now works for everyone, otherwise we’ll have to revert this test again. // 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
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
W dniu 31.08.2018 o 12:17, Martin Storsjö pisze: > On Aug 31, 2018, at 12:51, Mateusz wrote: >> >> W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: On Aug 29, 2018, at 18:44, Martell Malone wrote: LGTM. >>> >>> Pushed this version. >>> >>> // Martin >> >> It's not working for me (when I build gcc on ubuntu). >> Could we revert this patch? > > Maybe, but first I'd like to know more about what doesn't work for you. What > step fails for you? > > What does configure say about "Checking whether the linker provides > __CTOR_LIST__"? Do you use specifically binutils 2.30? Can you provide the > config.log from that run? > > // Martin binutils 2.31.1, config.log + config.h attached (from building gcc cross compiler on ubuntu) Mateusz This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by mingw-w64-runtime configure 4.0b, which was generated by GNU Autoconf 2.69. Invocation command line was $ /home/ma/m/source/mingw-w64-v6/mingw-w64-crt/configure --host=x86_64-w64-mingw32 --prefix=/home/ma/m/cross/x86_64-w64-mingw32 --enable-lib64 --disable-lib32 ## - ## ## Platform. ## ## - ## hostname = ma-VirtualBox uname -m = x86_64 uname -r = 4.15.0-33-generic uname -s = Linux uname -v = #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /home/ma/m/cross/bin PATH: /home/ma/bin PATH: /home/ma/.local/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games PATH: /usr/local/games PATH: /snap/bin ## --- ## ## Core tests. ## ## --- ## configure:2289: checking for a BSD-compatible install configure:2357: result: /usr/bin/install -c configure:2368: checking whether build environment is sane configure:2423: result: yes configure:2482: checking for x86_64-w64-mingw32-strip configure:2498: found /home/ma/m/cross/bin/x86_64-w64-mingw32-strip configure:2509: result: x86_64-w64-mingw32-strip configure:2574: checking for a thread-safe mkdir -p configure:2613: result: /bin/mkdir -p configure:2620: checking for gawk configure:2650: result: no configure:2620: checking for mawk configure:2636: found /usr/bin/mawk configure:2647: result: mawk configure:2658: checking whether make sets $(MAKE) configure:2680: result: yes configure:2709: checking whether make supports nested variables configure:2726: result: yes configure:2853: checking whether to enable maintainer-specific portions of Makefiles configure:2862: result: no configure:2880: checking build system type configure:2894: result: x86_64-unknown-linux-gnu configure:2914: checking host system type configure:2927: result: x86_64-w64-mingw32 configure:2948: checking for sysroot configure:2966: result: /home/ma/m/cross/x86_64-w64-mingw32 configure:2987: checking for a sed that does not truncate output configure:3051: result: /bin/sed configure:3060: checking for gawk configure:3087: result: mawk configure:3106: checking for x86_64-w64-mingw32-gcc configure:3122: found /home/ma/m/cross/bin/x86_64-w64-mingw32-gcc configure:3133: result: x86_64-w64-mingw32-gcc configure:3402: checking for C compiler version configure:3411: x86_64-w64-mingw32-gcc --version >&5 x86_64-w64-mingw32-gcc (GCC) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3422: $? = 0 configure:3411: x86_64-w64-mingw32-gcc -v >&5 Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/home/ma/m/cross/libexec/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/ma/m/source/gcc-8.2/configure --target=x86_64-w64-mingw32 --disable-nls --disable-multilib --with-gmp=/home/ma/m/build/for_cross --with-mpfr=/home/ma/m/build/for_cross --with-mpc=/home/ma/m/build/for_cross --with-isl=/home/ma/m/build/for_cross --enable-languages=c,c++,objc,obj-c++ --disable-libstdcxx-pch --disable-shared --enable-fully-dynamic-string --with-tune=core-avx2 --prefix=/home/ma/m/cross --with-sysroot=/home/ma/m/cross Thread model: win32 gcc version 8.2.0 (GCC) configure:3422: $? = 0 configure:3411: x86_64-w64-mingw32-gcc -V >&5 x86_64-w64-mingw32-gcc: error: unrecognized command line option '-V' x86_64-w64-mingw32-gcc: fatal error: no input files compilation terminated. configure:3422: $? = 1 configure:3411: x86_64-w64-mingw32-gcc -qversion >&5 x86_64-w64-mingw32-gcc: error: unrecognized command line option '-qversion'; did you mean '--version'? x86_64-w64-mingw32-gcc: fatal error: no input files compilation terminated. confi
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
On Aug 31, 2018, at 12:51, Mateusz wrote: > > W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >>> On Aug 29, 2018, at 18:44, Martell Malone wrote: >>> >>> LGTM. >> >> Pushed this version. >> >> // Martin > > It's not working for me (when I build gcc on ubuntu). > Could we revert this patch? Maybe, but first I'd like to know more about what doesn't work for you. What step fails for you? What does configure say about "Checking whether the linker provides __CTOR_LIST__"? Do you use specifically binutils 2.30? Can you provide the config.log from that run? // 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
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
W dniu 30.08.2018 o 09:53, Martin Storsjö pisze: >> On Aug 29, 2018, at 18:44, Martell Malone wrote: >> >> LGTM. > > Pushed this version. > > // Martin It's not working for me (when I build gcc on ubuntu). Could we revert this patch? Mateusz -- 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
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
> On Aug 29, 2018, at 18:44, Martell Malone wrote: > > LGTM. Pushed this version. // 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
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
LGTM.
Thanks for this.
When I originally used ifdef __clang__ we knew it was a hack because we
should be checking the linker and not the compiler but at the time clang
didn’t work well as a drop in replacement for gcc so it was used to specify
one toolchain combination or another.
Glad to see whe have come full circle now.
While linker interop is not possible for short import libs because ld
doesn’t support it, this is a step in the right direction.
On Wed 29 Aug 2018 at 05:09, Martin Storsjö wrote:
> Using the __clang__ ifdef isn't right; one could be using clang for
> compiling the mingw-w64 crt for use with binutils ld, which requires
> a slightly different setup of __CTOR_LIST__.
>
> Also, to ease interoperability between binutils ld and lld, lld could
> potentially start providing the __CTOR_LIST__ symbol, and in that case
> we shouldn't be providing it ourselves either.
>
> Signed-off-by: Martin Storsjö
> ---
> This time by setting ac_no_link=no temporarily at the same time as we are
> adding -nostdlib to LDFLAGS, to allow running the linker test even though
> target libraries aren't necessarily available yet.
> ---
> mingw-w64-crt/configure.ac | 48
> +
> mingw-w64-crt/crt/crtdll.c | 6 +-
> mingw-w64-crt/crt/crtexe.c | 6 +-
> mingw-w64-crt/crt/gccmain.c | 8 +++-
> 4 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
> index 6a42109..a492c1b 100644
> --- a/mingw-w64-crt/configure.ac
> +++ b/mingw-w64-crt/configure.ac
> @@ -301,6 +301,54 @@ AC_ARG_ENABLE([tests-unicode],
> AM_CONDITIONAL([ENABLE_TESTS_UNICODE],[test x$enable_tests_unicode =
> xyes])
> AC_MSG_RESULT([$enable_tests_unicode])
>
> +AC_MSG_CHECKING([whether the linker provides __CTOR_LIST__])
> +saved_LDFLAGS="$LDFLAGS"
> +saved_ac_no_link="$ac_no_link"
> +LDFLAGS="$LDFLAGS -nostdlib"
> +# Force ac_no_link to "no". When bootstrapping an environment, autoconf
> will
> +# earlier conclude that linking isn't possible (since -lmingw32 etc are
> +# missing), and set ac_no_link=yes. This forbids us from doing a test with
> +# AC_LINK_IFELSE here, even though we are knowingly setting -nostdlib, to
> +# make this specific testcase work even though the normally linked
> libraries
> +# aren't available yet. Override this variable to allow us to perform the
> link
> +# test.
> +ac_no_link=no
> +# Note that binutils 2.30 is broken with respect to __CTOR_LIST__ (the
> change
> +# was reverted for 2.31); it does provide __CTOR_LIST__ automatically
> only if
> +# necessary. But as long as there's no other definition of it, a fallback
> +# __CTOR_LIST__ gets pulled in from libgcc, and this fallback is only a
> dummy
> +# to prevent linker errors (in general) and isn't assigned to the right
> +# sections. Therefore, it'd be better to test whether we can/should
> provide
> +# our own __CTOR_LIST__.
> +
> +# But we can't test whether we can provide our own __CTOR_LIST__ with
> binutils
> +# ld either; even if our test provides its own symbol __CTOR_LIST__, ld
> will
> +# include it but silently use its own provided __CTOR_LIST__ instead, and
> +# won't error out. For actual real use, that'd mean a stray broken
> pointer in
> +# the .ctors section.
> +
> +# This test uses both mainCRTStartup and main functions, to let lld deduce
> +# entry point and subsystem automatically without having to manually
> specify,
> +# anything. And as long as main() is provided, we need to implicitly
> provide
> +# __main as well, since the compiler injects a call to it.
> +AC_LINK_IFELSE([AC_LANG_SOURCE([[
> +#include
> +extern const void * __CTOR_LIST__;
> +void __main(void) {
> +}
> +int main(void) {
> + return (int)(intptr_t)__CTOR_LIST__;
> +}
> +int mainCRTStartup(void) {
> + return main();
> +}
> +]])],
> +[AC_DEFINE([HAVE_CTOR_LIST],[1],[Whether the linker provides
> __CTOR_LIST__])
> +AC_MSG_RESULT(yes)],
> +[AC_MSG_RESULT(no)])
> +LDFLAGS="$saved_LDFLAGS"
> +ac_no_link="$saved_ac_no_link"
> +
> # Checks for libraries.
>
> # Checks for header files.
> diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
> index 5f53602..6187f10 100644
> --- a/mingw-w64-crt/crt/crtdll.c
> +++ b/mingw-w64-crt/crt/crtdll.c
> @@ -10,6 +10,10 @@
> #define _DLL
> #endif
>
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> #include
> #include
> #include
> @@ -40,7 +44,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
> extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
> extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
>
> -#ifdef __clang__
> +#ifndef HAVE_CTOR_LIST
> __attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void
> * const void * __CTOR_LIST__ = (void *) -1;
> __attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void
> * const void * __DTOR_LIST__ = (void *) -1;
> __attribute__ (( __section__ (".ctors.9"), __used__ ,
> aligned(sizeof(void * const void * __CTOR
[Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
Using the __clang__ ifdef isn't right; one could be using clang for
compiling the mingw-w64 crt for use with binutils ld, which requires
a slightly different setup of __CTOR_LIST__.
Also, to ease interoperability between binutils ld and lld, lld could
potentially start providing the __CTOR_LIST__ symbol, and in that case
we shouldn't be providing it ourselves either.
Signed-off-by: Martin Storsjö
---
This time by setting ac_no_link=no temporarily at the same time as we are
adding -nostdlib to LDFLAGS, to allow running the linker test even though
target libraries aren't necessarily available yet.
---
mingw-w64-crt/configure.ac | 48 +
mingw-w64-crt/crt/crtdll.c | 6 +-
mingw-w64-crt/crt/crtexe.c | 6 +-
mingw-w64-crt/crt/gccmain.c | 8 +++-
4 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index 6a42109..a492c1b 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -301,6 +301,54 @@ AC_ARG_ENABLE([tests-unicode],
AM_CONDITIONAL([ENABLE_TESTS_UNICODE],[test x$enable_tests_unicode = xyes])
AC_MSG_RESULT([$enable_tests_unicode])
+AC_MSG_CHECKING([whether the linker provides __CTOR_LIST__])
+saved_LDFLAGS="$LDFLAGS"
+saved_ac_no_link="$ac_no_link"
+LDFLAGS="$LDFLAGS -nostdlib"
+# Force ac_no_link to "no". When bootstrapping an environment, autoconf will
+# earlier conclude that linking isn't possible (since -lmingw32 etc are
+# missing), and set ac_no_link=yes. This forbids us from doing a test with
+# AC_LINK_IFELSE here, even though we are knowingly setting -nostdlib, to
+# make this specific testcase work even though the normally linked libraries
+# aren't available yet. Override this variable to allow us to perform the link
+# test.
+ac_no_link=no
+# Note that binutils 2.30 is broken with respect to __CTOR_LIST__ (the change
+# was reverted for 2.31); it does provide __CTOR_LIST__ automatically only if
+# necessary. But as long as there's no other definition of it, a fallback
+# __CTOR_LIST__ gets pulled in from libgcc, and this fallback is only a dummy
+# to prevent linker errors (in general) and isn't assigned to the right
+# sections. Therefore, it'd be better to test whether we can/should provide
+# our own __CTOR_LIST__.
+
+# But we can't test whether we can provide our own __CTOR_LIST__ with binutils
+# ld either; even if our test provides its own symbol __CTOR_LIST__, ld will
+# include it but silently use its own provided __CTOR_LIST__ instead, and
+# won't error out. For actual real use, that'd mean a stray broken pointer in
+# the .ctors section.
+
+# This test uses both mainCRTStartup and main functions, to let lld deduce
+# entry point and subsystem automatically without having to manually specify,
+# anything. And as long as main() is provided, we need to implicitly provide
+# __main as well, since the compiler injects a call to it.
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
+#include
+extern const void * __CTOR_LIST__;
+void __main(void) {
+}
+int main(void) {
+ return (int)(intptr_t)__CTOR_LIST__;
+}
+int mainCRTStartup(void) {
+ return main();
+}
+]])],
+[AC_DEFINE([HAVE_CTOR_LIST],[1],[Whether the linker provides __CTOR_LIST__])
+AC_MSG_RESULT(yes)],
+[AC_MSG_RESULT(no)])
+LDFLAGS="$saved_LDFLAGS"
+ac_no_link="$saved_ac_no_link"
+
# Checks for libraries.
# Checks for header files.
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 5f53602..6187f10 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -10,6 +10,10 @@
#define _DLL
#endif
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include
#include
#include
@@ -40,7 +44,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".ctors.9"), __used__ , aligned(sizeof(void
* const void * __CTOR_END__ = (void *) 0;
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 80e0556..361afd2 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -9,6 +9,10 @@
#define _DLL
#endif
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#define SPECIAL_CRTEXE
#include
@@ -64,7 +68,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LI
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
> On Aug 28, 2018, at 05:58, Liu Hao wrote: > > 在 2018/8/28 2:50, Martin Storsjö 写道: >> Using the __clang__ ifdef isn't right; one could be using clang for >> compiling the mingw-w64 crt for use with binutils ld, which requires >> a slightly different setup of __CTOR_LIST__. >> >> Also, to ease interoperability between binutils ld and lld, lld could >> potentially start providing the __CTOR_LIST__ symbol, and in that case >> we shouldn't be providing it ourselves either. >> >> Signed-off-by: Martin Storsjö >> --- >> > > This patch looks good to me. Pushed. And later reverted, since I had only tested it in a build on top of an existing environment. When bootstrapping, autoconf earlier tests whether linking works (it doesn't, since the mingw crt isn't built yet) and then later refuses to run this linker test, even though this test would have worked as intended (since it uses -nostdlib). Will try to tweak it to make it work around these autoconf issues and post a new patch later... // 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
Re: [Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
在 2018/8/28 2:50, Martin Storsjö 写道: > Using the __clang__ ifdef isn't right; one could be using clang for > compiling the mingw-w64 crt for use with binutils ld, which requires > a slightly different setup of __CTOR_LIST__. > > Also, to ease interoperability between binutils ld and lld, lld could > potentially start providing the __CTOR_LIST__ symbol, and in that case > we shouldn't be providing it ourselves either. > > Signed-off-by: Martin Storsjö > --- > This patch looks good to me. -- Best regards, LH_Mouse -- 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
[Mingw-w64-public] [PATCH] crt: Check whether the linker provides __CTOR_LIST__, don't check for __clang__
Using the __clang__ ifdef isn't right; one could be using clang for
compiling the mingw-w64 crt for use with binutils ld, which requires
a slightly different setup of __CTOR_LIST__.
Also, to ease interoperability between binutils ld and lld, lld could
potentially start providing the __CTOR_LIST__ symbol, and in that case
we shouldn't be providing it ourselves either.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/configure.ac | 38 ++
mingw-w64-crt/crt/crtdll.c | 6 +-
mingw-w64-crt/crt/crtexe.c | 6 +-
mingw-w64-crt/crt/gccmain.c | 8 +++-
4 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index 6a42109..b235885 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -301,6 +301,44 @@ AC_ARG_ENABLE([tests-unicode],
AM_CONDITIONAL([ENABLE_TESTS_UNICODE],[test x$enable_tests_unicode = xyes])
AC_MSG_RESULT([$enable_tests_unicode])
+AC_MSG_CHECKING([whether the linker provides __CTOR_LIST__])
+saved_LDFLAGS="$LDFLAGS"
+LDFLAGS="$LDFLAGS -nostdlib"
+# Note that binutils 2.30 is broken with respect to __CTOR_LIST__ (the change
+# was reverted for 2.31); it does provide __CTOR_LIST__ automatically only if
+# necessary. But as long as there's no other definition of it, a fallback
+# __CTOR_LIST__ gets pulled in from libgcc, and this fallback is only a dummy
+# to prevent linker errors (in general) and isn't assigned to the right
+# sections. Therefore, it'd be better to test whether we can/should provide
+# our own __CTOR_LIST__.
+
+# But we can't test whether we can provide our own __CTOR_LIST__ with binutils
+# ld either; even if our test provides its own symbol __CTOR_LIST__, ld will
+# include it but silently use its own provided __CTOR_LIST__ instead, and
+# won't error out. For actual real use, that'd mean a stray broken pointer in
+# the .ctors section.
+
+# This test uses both mainCRTStartup and main functions, to let lld deduce
+# entry point and subsystem automatically without having to manually specify,
+# anything. And as long as main() is provided, we need to implicitly provide
+# __main as well, since the compiler injects a call to it.
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
+#include
+extern const void * __CTOR_LIST__;
+void __main(void) {
+}
+int main(void) {
+ return (int)(intptr_t)__CTOR_LIST__;
+}
+int mainCRTStartup(void) {
+ return main();
+}
+]])],
+[AC_DEFINE([HAVE_CTOR_LIST],[1],[Whether the linker provides __CTOR_LIST__])
+AC_MSG_RESULT(yes)],
+[AC_MSG_RESULT(no)])
+LDFLAGS="$saved_LDFLAGS"
+
# Checks for libraries.
# Checks for header files.
diff --git a/mingw-w64-crt/crt/crtdll.c b/mingw-w64-crt/crt/crtdll.c
index 5f53602..6187f10 100644
--- a/mingw-w64-crt/crt/crtdll.c
+++ b/mingw-w64-crt/crt/crtdll.c
@@ -10,6 +10,10 @@
#define _DLL
#endif
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include
#include
#include
@@ -40,7 +44,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".ctors.9"), __used__ , aligned(sizeof(void
* const void * __CTOR_END__ = (void *) 0;
diff --git a/mingw-w64-crt/crt/crtexe.c b/mingw-w64-crt/crt/crtexe.c
index 80e0556..361afd2 100644
--- a/mingw-w64-crt/crt/crtexe.c
+++ b/mingw-w64-crt/crt/crtexe.c
@@ -9,6 +9,10 @@
#define _DLL
#endif
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#define SPECIAL_CRTEXE
#include
@@ -64,7 +68,7 @@ extern _CRTALLOC(".CRT$XIZ") _PIFV __xi_z[];
extern _CRTALLOC(".CRT$XCA") _PVFV __xc_a[];
extern _CRTALLOC(".CRT$XCZ") _PVFV __xc_z[];
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *
const void * __CTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *
const void * __DTOR_LIST__ = (void *) -1;
__attribute__ (( __section__ (".ctors.9"), __used__ , aligned(sizeof(void
* const void * __CTOR_END__ = (void *) 0;
diff --git a/mingw-w64-crt/crt/gccmain.c b/mingw-w64-crt/crt/gccmain.c
index 54cbf02..030cdce 100644
--- a/mingw-w64-crt/crt/gccmain.c
+++ b/mingw-w64-crt/crt/gccmain.c
@@ -8,6 +8,10 @@
#include
#include
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
typedef void (*func_ptr) (void);
extern func_ptr __CTOR_LIST__[];
extern func_ptr __DTOR_LIST__[];
@@ -28,7 +32,9 @@ __do_global_dtors (void)
}
}
-#ifdef __clang__
+#ifndef HAVE_CTOR_LIST
+// If the linker didn't provide __CTOR_LIST__, we provided it ourselves,
+// and then we also know we have __CTOR_END__ available.
extern func_ptr _
