[I have trimmed out the numerical debian address, since I don't know if
this is relevant to that list(?), and since I don't know if Debian's
firm policy of outing people's email address in clear has changed.]
"Steve M. Robbins" <steve at sumost.ca> writes:
Matches my experience: I cannot reproduce the crash using reproducer.c
on my physical amd64.
GMP was written for compatibility with all existing processors in
mainstream 32-bit and 64-bit processor families. Trying to be
compatible with emulators is a different task entirely.
Interesting. It could well be the configure option. For the past 6
years, Debian built using --disable-fat on amd64. I changed it
because there are both bug workarounds and code speedups that are
processor-based.
Changed it to --disable-fat a couple of years ago with that aim, or
changed it away from --disable-fat now with that aim?
If you are aware of any bugs that will exist only in fat or only in
non-fat GMP builds, the GMP project would like to know about that.
So it makes more sense for the code to detect the
processor at runtime.
That makes sense (also) for entrierly different reasons.
On the other hand, I just looked at the source diff and there is a
change in configure.guess that changes the behaviour for a 64-bit
"vmkernel". Could this be affecting your virtual machine?
Note that he's not talking about GMP here, this is no GMP patch.
@@ -1315,6 +1325,9 @@
i*86:AROS:*:*)
echo ${UNAME_MACHINE}-pc-aros
exit ;;
+ x86_64:VMkernel:*:*)
+ echo ${UNAME_MACHINE}-unknown-esx
+ exit ;;
No idea why your emulator doesn't emulate hardware to GMP's
satisfaction. Some instruction is probably not emulated correctly.
I've seen cases where emulators claim 64-bittyness and non-64-bittyness
at the same time (such as 486 with AMD64 insns), and even had suggested
patch to GMP a while ago with a workaround...
--
Torbjörn