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
Re: gmp 6.2.0 documentation bug
> On 29 Sep 2020, at 19:17, Marco Bodrato wrote:
>
> Il 2020-09-29 16:09 TonyMcC ha scritto:
>> I think there is a word (a function name?) missing from the
>> documentation for gmp 6.2.0. In gmp.texi, at line 2541 it reads:
>> "it's probably best to call to get a starting point and iterate from there."
>> Should there be a function name after "call"?
>
> The complete sentence is:
>
> Functions like @code{mpz_fac_ui}, @code{mpz_fib_ui} and @code{mpz_bin_uiui}
> are designed for calculating isolated values. If a range of values is wanted
> it's probably best to call to get a starting point and iterate from there.
>
> Maybe we can simply remove "to call".
>
> The documentation of mpz_fib_ui correctly suggests the function to call:
> mpz_fib2_ui.
>
> Speaking about mpz_fac_ui and mpz_bin_uiui, it shouldn't be necessary to
> suggest how to get the starting point.
It might say:
If a range of values is wanted, see the definition respective function.
Since it is properly described for first two. For the binomials, it would be
most efficient to compute the trapezoid above the values in Pascal's triangle,
I would think, and the function does not provide an efficient way to get that.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
