Re: COFF_TYPE on x86_64
On Mon, 2 Nov 2020, Marco Bodrato wrote: > Ciao Jeremy, > > Il 2020-10-02 20:45 Jeremy Drake ha scritto: > > Looking at the ld code, it only generated the thunk in the import library > > if it thought the symbol was a function. Checking the output of gcc -S > > showed that it added ".def func; .scl 2; .type 32; .endef" to functions, > > and inserting that into the assembly functions caused ld to generate the > > thunks, which solved the crash. When I started to investigate how to > > integrate generating that in the GMP build system, I came across existing > > code that did exactly that, but only on 32-bit x86 not x86_64. The patch > > I sent copied the necessary parts of that to the x86_64 path. > > Can you test if the latest available snapshot is working in your environment? Yes, I have confirmed that the snapshot generates a correct import lib. Thank you. > Do you know if this might be needed also for mingw running on ARM cpus? Disclaimer: I have no personal experience with mingw or Windows on ARM. However, after looking through binutils code, and looking at -S output from clang targeting both armv7 and aarch64 mingw, it appears to me that it would be needed on ARM as well. ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: COFF_TYPE on x86_64
Ciao Jeremy, Il 2020-10-02 20:45 Jeremy Drake ha scritto: Looking at the ld code, it only generated the thunk in the import library if it thought the symbol was a function. Checking the output of gcc -S showed that it added ".def func; .scl 2; .type 32; .endef" to functions, and inserting that into the assembly functions caused ld to generate the thunks, which solved the crash. When I started to investigate how to integrate generating that in the GMP build system, I came across existing code that did exactly that, but only on 32-bit x86 not x86_64. The patch I sent copied the necessary parts of that to the x86_64 path. Can you test if the latest available snapshot is working in your environment? You can download it at: https://gmplib.org/download/snapshot/gmp-6.2/gmp-6.2.0-20201101220635.tar.zst Do you know if this might be needed also for mingw running on ARM cpus? Ĝis, m ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: COFF_TYPE on x86_64
Jeremy Drake writes: I anchored the link to a particular line: My bad, I didn't see that. > Strangely, the fix for this was only applied to x86, and not x86_64. This > patch applies the fix to x86_64. > > What *fix* are you talking about? https://gmplib.org/repo/gmp-6.2/rev/0a17b90462e6 You have to forgive me for not guessing that. My memory of 17 year old patches are a bit dim. And considering that amd64 did not exist at the time of that patch, it is not strange that it wasn't applied to the equally non-existing mpn/x86_64 directory. I sent copied the necessary parts of that to the x86_64 path. OK, I'll take a look. > I recently tried to install msys2 on a Windos 10 system here. I had > some problems and tried to contact the msys2 people at their mailing > list. The message was silently dropped. Thus, I gave up on msys2 and > returned to cygwin. That's our path forward now. I think they are no longer using sourceforge, and are on github. https://github.com/msys2/ They are also on https://gitter.im/msys2/msys2 You guess better than me. Yes, I indeed mailed to the msys2 sourceforge list. And they set up the mailing list to silently drop (as opposed to at last bounce or ideally forward) incoming mail? Unimpressive. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: COFF_TYPE on x86_64
On Fri, 2 Oct 2020, Torbjörn Granlund wrote: > https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128 > > This is a link to a huge file. Many things are mentioned there. I anchored the link to a particular line: dnl On MINGW, recent versions of the linker have an automatic import scheme dnl for data in a DLL which is referenced by a mainline but without dnl __declspec (__dllimport__) on the prototype. It seems functions dnl without type information are treated as data, or something, and calls dnl to them from the mainline will crash. gcc puts type information on the dnl C functions it generates, we need to do the same for assembler dnl functions. > > Strangely, the fix for this was only applied to x86, and not x86_64. This > patch applies the fix to x86_64. > > What *fix* are you talking about? https://gmplib.org/repo/gmp-6.2/rev/0a17b90462e6 > You need to give us some context. Please allow yourself a little time > to word your message to give us a chance to follow you. Context/backstory: we recently started enabling more security options in the linker, including ASLR. On x86_64, the ASLR variant that relocates DLLs above 4GB addresses caused a crash when applied to GCC. After much debugging and consternation, I tracked the problem down to how GCC (technically mpfr) linked to GMP. It seemed that when ld.bfd generated the import library (libgmp.dll.a) it didn't generate a 'jmp thunk' symbol for the asm functions, resulting in only using a 32-bit relative offset when calling those functions. With the truncated relocation, the call would go off somewhere other than where it should have, and crash. Looking at the ld code, it only generated the thunk in the import library if it thought the symbol was a function. Checking the output of gcc -S showed that it added ".def func; .scl 2; .type 32; .endef" to functions, and inserting that into the assembly functions caused ld to generate the thunks, which solved the crash. When I started to investigate how to integrate generating that in the GMP build system, I came across existing code that did exactly that, but only on 32-bit x86 not x86_64. The patch I sent copied the necessary parts of that to the x86_64 path. > > I recently tried to install msys2 on a Windos 10 system here. I had > some problems and tried to contact the msys2 people at their mailing > list. The message was silently dropped. Thus, I gave up on msys2 and > returned to cygwin. That's our path forward now. I think they are no longer using sourceforge, and are on github. https://github.com/msys2/ They are also on https://gitter.im/msys2/msys2 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
COFF_TYPE on x86_64
On msys2's MINGW-packages, we recently hit an issue[1] which I eventually tracked down to the very issue documented in https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128 > > My current theory is that for some unknown reason, gmp's assembly > > functions are resulting in symbols that bfd believes are data, not > > functions. Without dllimport, this is causing it to use the > > auto-import hack, which has the Windows loader modify addresses in the > > function itself, rather than using the jmp thunk which references the > > `__imp_` symbol. This cannot work correctly on x64 with large > > addresses, because the CALL instruction is taking a 32-bit relative > > operand. The only way this can work is with a jmp thunk (unless the > > compiler knew to generate an indirect CALL, which is what dllimport > > does). > > The 'unknown reason' I mentioned is that the functions were lacking > `.type 32`. > > > gmp's configure script checks for support for .type pseudo-op, but on > > mingw that is only allowed inside a .def, and must take an integer not > > `@function`, so gmp suppresses it altogether. Strangely, the fix for this was only applied to x86, and not x86_64. This patch applies the fix to x86_64. [1]: https://github.com/msys2/MINGW-packages/issues/6983--- gmp-6.2.0/mpn/x86_64/x86_64-defs.m4.orig2020-10-01 22:00:35.891856900 -0700 +++ gmp-6.2.0/mpn/x86_64/x86_64-defs.m4 2020-10-01 22:01:29.579372600 -0700 @@ -93,10 +93,28 @@ m4_assert_numargs(1) ` GLOBL $1 TYPE($1,`function') + COFF_TYPE($1) $1: ') +dnl Usage: COFF_TYPE(GSYM_PREFIX`'foo) +dnl +dnl Emit COFF style ".def ... .endef" type information for a function, when +dnl supported. The argument should include any GSYM_PREFIX. +dnl +dnl See autoconf macro GMP_ASM_COFF_TYPE for HAVE_COFF_TYPE. + +define(COFF_TYPE, +m4_assert_numargs(1) +m4_assert_defined(`HAVE_COFF_TYPE') +`ifelse(HAVE_COFF_TYPE,yes, + `.def $1 + .scl2 + .type 32 + .endef')') + + dnl Usage: ASSERT([cond][,instructions]) dnl dnl If WANT_ASSERT is 1, output the given instructions and expect the given --- gmp-6.2.0/configure.ac.orig 2020-10-01 22:24:41.048101000 -0700 +++ gmp-6.2.0/configure.ac 2020-10-01 22:24:56.657479600 -0700 @@ -3792,6 +3792,7 @@ 64|x32) GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) AC_DEFINE(HAVE_HOST_CPU_FAMILY_x86_64) + GMP_ASM_COFF_TYPE case $host in *-*-darwin*) GMP_INCLUDE_MPN(x86_64/darwin.m4) ;; ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: COFF_TYPE on x86_64
On Friday, October 2, 2020 12:59:10 P.M. CDT Torbjörn Granlund wrote: > Jeremy Drake writes: > > On msys2's MINGW-packages, we recently hit an issue[1] which I eventually > tracked down to the very issue documented in > https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128 > > This is a link to a huge file. Many things are mentioned there. But, to be fair, it is a link to a specific line -- 2128 -- which documents one specific thing: dnl On MINGW, recent versions of the linker have an automatic import scheme dnl for data in a DLL which is referenced by a mainline but without dnl __declspec (__dllimport__) on the prototype. It seems functions dnl without type information are treated as data, or something, and calls dnl to them from the mainline will crash. gcc puts type information on the dnl C functions it generates, we need to do the same for assembler dnl functions. dnl dnl This applies only to functions without __declspec(__dllimport__), dnl ie. without __GMP_DECLSPEC in the case of libgmp, so it also works just dnl to ensure all assembler functions used from outside libgmp have dnl __GMP_DECLSPEC on their prototypes. But this isn't an ideal situation, dnl since we don't want perfectly valid calls going wrong just because dnl there wasn't a prototype in scope. dnl dnl When an auto-import takes place, the following warning is given by the dnl linker. This shouldn't be seen for any functions. dnl dnl Info: resolving _foo by linking to __imp__foo (auto-import) dnl dnl dnl COFF type directives look like the following dnl dnl .def_foo dnl .scl2 dnl .type 32 dnl .endef dnl dnl _foo is the symbol with GSYM_PREFIX (_). .scl is the storage class, 2 dnl for external, 3 for static. .type is the object type, 32 for a dnl function. dnl dnl On an ELF system, this is (correctly) rejected due to .def, .endef and + −dnl .scl being invalid, and .type not having enough arguments. signature.asc Description: This is a digitally signed message part. ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
Re: COFF_TYPE on x86_64
Jeremy Drake writes: On msys2's MINGW-packages, we recently hit an issue[1] which I eventually tracked down to the very issue documented in https://gmplib.org/repo/gmp-6.2/file/09e101b6f2ff/acinclude.m4#l2128 This is a link to a huge file. Many things are mentioned there. > > My current theory is that for some unknown reason, gmp's assembly > > functions are resulting in symbols that bfd believes are data, not > > functions. Without dllimport, this is causing it to use the > > auto-import hack, which has the Windows loader modify addresses in the > > function itself, rather than using the jmp thunk which references the > > `__imp_` symbol. This cannot work correctly on x64 with large > > addresses, because the CALL instruction is taking a 32-bit relative > > operand. The only way this can work is with a jmp thunk (unless the > > compiler knew to generate an indirect CALL, which is what dllimport > > does). > > The 'unknown reason' I mentioned is that the functions were lacking > `.type 32`. > > > gmp's configure script checks for support for .type pseudo-op, but on > > mingw that is only allowed inside a .def, and must take an integer not > > `@function`, so gmp suppresses it altogether. Strangely, the fix for this was only applied to x86, and not x86_64. This patch applies the fix to x86_64. What *fix* are you talking about? You need to give us some context. Please allow yourself a little time to word your message to give us a chance to follow you. I recently tried to install msys2 on a Windos 10 system here. I had some problems and tried to contact the msys2 people at their mailing list. The message was silently dropped. Thus, I gave up on msys2 and returned to cygwin. That's our path forward now. -- Torbjörn Please encrypt, key id 0xC8601622 ___ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
