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