COFF_TYPE on x86_64
gmp at jdrake.com
Fri Oct 2 17:18:16 UTC 2020
On msys2's MINGW-packages, we recently hit an issue which I eventually
tracked down to the very issue documented in
> > 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.
-------------- next part --------------
--- gmp-6.2.0/mpn/x86_64/x86_64-defs.m4.orig 2020-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 @@
` GLOBL $1
+dnl Usage: COFF_TYPE(GSYM_PREFIX`'foo)
+dnl Emit COFF style ".def ... .endef" type information for a function, when
+dnl supported. The argument should include any GSYM_PREFIX.
+dnl See autoconf macro GMP_ASM_COFF_TYPE for HAVE_COFF_TYPE.
+ `.def $1
+ .scl 2
+ .type 32
dnl Usage: ASSERT([cond][,instructions])
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 @@
case $host in
More information about the gmp-bugs