COFF_TYPE on x86_64
steve at sumost.ca
Fri Oct 2 18:09:13 UTC 2020
On Friday, October 2, 2020 12:59:10 P.M. CDT Torbjörn Granlund wrote:
> Jeremy Drake <gmp at jdrake.com> writes:
> On msys2's MINGW-packages, we recently hit an issue which I eventually
> tracked down to the very issue documented in
> This is a link to a huge file. Many things are mentioned there.
But, to be fair, it is a link to a specific line -- 2128 -- which documents one
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 This applies only to functions without __declspec(__dllimport__),
dnl ie. without __GMP_DECLSPEC in the case of libgmp, so it also works just
dnl to ensure all assembler functions used from outside libgmp have
dnl __GMP_DECLSPEC on their prototypes. But this isn't an ideal situation,
dnl since we don't want perfectly valid calls going wrong just because
dnl there wasn't a prototype in scope.
dnl When an auto-import takes place, the following warning is given by the
dnl linker. This shouldn't be seen for any functions.
dnl Info: resolving _foo by linking to __imp__foo (auto-import)
dnl COFF type directives look like the following
dnl .def _foo
dnl .scl 2
dnl .type 32
dnl _foo is the symbol with GSYM_PREFIX (_). .scl is the storage class, 2
dnl for external, 3 for static. .type is the object type, 32 for a
dnl On an ELF system, this is (correctly) rejected due to .def, .endef and
−dnl .scl being invalid, and .type not having enough arguments.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the gmp-bugs