GMP MIPS64 divrem_1.asm bug?
tg at swox.com
Thu Sep 25 21:49:17 CEST 2008
"Himlin, Bob" <bob.himlin at viasat.com> writes:
I am running GMP on a Cavium Networks Octeon board, and trying to use
64-bit mode, e.g. mabi=64. The software package was originally complied
and runs on the same hardware in 32-bit mode (mabi=n32). I have run into
the following issue with mpn/mips64/divrem_1.asm, which uses ADDU instead
of DADDU to manipulate addresses. The first example that tripped me up
(though there are others, I am sure), is the last few lines of the
following snip, which uses ADDU instead of DADDU to adjust a passed-in
pointer, inadvertently making it a 32-bit address, then tries to access
memory at that address causing a segmentation fault.
I am interested to hear if there is a simple solution to this - how is it
that the library is used on MIPS64 with this error? Do not all MIPS64
behave the same way?
This surely looks like a bug affecting the ABI "64", but not the o32
or n32 ABIs.
I don't think the MIPS GMP code gets a lot of testing these days. The
automated GMP build system does run on an ancient MIPS Irix system,
but this system does not seem to allocate anything at high enough
addresses for this bug to be triggered.
I don't feel comfortable editing the MIPS files, since I am not
familiar with the the ABIs. For example, are 32-bit types used as
arguments zero extended when passed as parameters? If they are not,
meaning the callee needs to extend them, we cannot safely change the
ADDUs to DADDUs, the SLLs to DSLLs, etc.
The best fix might be to simply delete mips64/divrem_1.asm.
More information about the gmp-bugs