COFF_TYPE on x86_64

Torbjörn Granlund tg at gmplib.org
Fri Oct 2 17:59:10 UTC 2020


Jeremy Drake <gmp at jdrake.com> 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


More information about the gmp-bugs mailing list