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