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
Re: [Mingw-w64-public] [PATCH] libmincore.a: Add new importlib.
On Mon, 27 Aug 2018, Jacek Caban wrote: On 08/27/2018 08:44 PM, Martin Storsjö wrote: On Mon, 27 Aug 2018, Jacek Caban wrote: Please review the attached patch. Note that it adds .mri file in a different way than those that are currently in the tree. I don't like how much copy between arch-specific rules it would require otherwise. Being not an expert of autoconf, I'd appreciate good review of those parts. --- mingw-w64-crt/Makefile.am | 67 .../lib-common/api-ms-win-core-version-l1-1-1.def | 10 ++ mingw-w64-crt/lib-common/mincore.mri | 168 + mingw-w64-crt/lib32/Makefile.am | 1 + .../lib32/api-ms-win-core-version-l1-1-1.def | 10 ++ mingw-w64-crt/lib64/Makefile.am | 1 + mingw-w64-crt/libarm32/Makefile.am | 1 + mingw-w64-crt/libarm64/Makefile.am | 1 + 8 files changed, 259 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def create mode 100644 mingw-w64-crt/lib-common/mincore.mri create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def LGTM I'd also appreciate a patch that does similar deduplication for the other existing .mri files :-) Thanks, I will push it. I will plan to look at other cases, but I'd prefer to wait for a while to make sure that there are no issues with this approach. Ok, that sounds sensible. // 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] libmincore.a: Add new importlib.
On 08/27/2018 08:44 PM, Martin Storsjö wrote: > On Mon, 27 Aug 2018, Jacek Caban wrote: > >> Please review the attached patch. >> >> Note that it adds .mri file in a different way than those that are >> currently in the tree. I don't like how much copy between >> arch-specific rules it would require otherwise. Being not an expert of >> autoconf, I'd appreciate good review of those parts. >> >> --- >> mingw-w64-crt/Makefile.am | 67 >> .../lib-common/api-ms-win-core-version-l1-1-1.def | 10 ++ >> mingw-w64-crt/lib-common/mincore.mri | 168 >> + >> mingw-w64-crt/lib32/Makefile.am | 1 + >> .../lib32/api-ms-win-core-version-l1-1-1.def | 10 ++ >> mingw-w64-crt/lib64/Makefile.am | 1 + >> mingw-w64-crt/libarm32/Makefile.am | 1 + >> mingw-w64-crt/libarm64/Makefile.am | 1 + >> 8 files changed, 259 insertions(+) >> create mode 100644 >> mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def >> create mode 100644 mingw-w64-crt/lib-common/mincore.mri >> create mode 100644 >> mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def > > LGTM > > I'd also appreciate a patch that does similar deduplication for the > other existing .mri files :-) Thanks, I will push it. I will plan to look at other cases, but I'd prefer to wait for a while to make sure that there are no issues with this approach. Jacek -- 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
Re: [Mingw-w64-public] [PATCH] libmincore.a: Add new importlib.
On Mon, 27 Aug 2018, Jacek Caban wrote: Please review the attached patch. Note that it adds .mri file in a different way than those that are currently in the tree. I don't like how much copy between arch-specific rules it would require otherwise. Being not an expert of autoconf, I'd appreciate good review of those parts. --- mingw-w64-crt/Makefile.am | 67 .../lib-common/api-ms-win-core-version-l1-1-1.def | 10 ++ mingw-w64-crt/lib-common/mincore.mri | 168 + mingw-w64-crt/lib32/Makefile.am| 1 + .../lib32/api-ms-win-core-version-l1-1-1.def | 10 ++ mingw-w64-crt/lib64/Makefile.am| 1 + mingw-w64-crt/libarm32/Makefile.am | 1 + mingw-w64-crt/libarm64/Makefile.am | 1 + 8 files changed, 259 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-version-l1-1-1.def create mode 100644 mingw-w64-crt/lib-common/mincore.mri create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-version-l1-1-1.def LGTM I'd also appreciate a patch that does similar deduplication for the other existing .mri files :-) // 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: Unify and simplify handling of constructor/destructor lists
On Mon, 27 Aug 2018, Liu Hao wrote: This patch breaks libgcc. At the moment the `__main()` function which performs global initialization for static objects cannot handle `__CTOR_LIST__` with two pointers of `-1` in the front of it [1]. The code is presumed to call every function via pointers between the first `-1` and final null terminator in reverse order, which, if the second element is a duplicated `-1`, will result in a segfault at the last iteration of the loop. To clarify; mingw-w64-crt has got its own __main function, while libgcc provides another one. The one in mingw-w64 should handle this just fine, while the libgcc ones obviously doesn't. Probably this patch should be reverted. Yes, unless we come up with something better, soon. Feel free to revert, but please amend the commit message to clarify that there are two different implementations of the __main function; the one we have worked fine but the libgcc one didn't handle our special situation. I had an idea to try to move the defintion of these symbols from crtexe.c/crtdll.c into gccmain.c, but that makes them turn up too late in the link, after constructors from some object files, so that doesn't really work. If we revert this, my next alternative towards unifying this handling across binutils and lld, would be to first make mingw-w64 check for these symbols during the build so we can make the previous ifdefs a bit more flexible (not having to check for #ifdef __clang__, which the compiler doesn't say what linker one was going to use) - I have a pretty much ready patch for this already. Then secondly, we could make lld provide the symbols, to make things with gcc+binutils behave the same as with clang+lld, making the CRT object files compatible across both linkers at the same time. // 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: Unify and simplify handling of constructor/destructor lists
This patch breaks libgcc. At the moment the `__main()` function which performs global initialization for static objects cannot handle `__CTOR_LIST__` with two pointers of `-1` in the front of it [1]. The code is presumed to call every function via pointers between the first `-1` and final null terminator in reverse order, which, if the second element is a duplicated `-1`, will result in a segfault at the last iteration of the loop. Probably this patch should be reverted. [1] https://github.com/gcc-mirror/gcc/blob/master/libgcc/gbl-ctors.h#L75 -- 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
