COFF_TYPE on x86_64

[Jeremy Drake]

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