https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300
Maciej W. Rozycki <ma...@linux-mips.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ma...@linux-mips.org
--- Comment #2 from Maciej W. Rozycki <ma...@linux-mips.org> ---
Thank you for your bug report.
The SVR4 MIPS psABI (o32) mandates that a HI16 or a local GOT16
relocation is immediately followed by a matching LO16 relocation. To
address the very scenario described here however as a GNU extension we
support an arbitrary number of HI16 or GOT16 relocations followed by a
matching LO16 relocation. This is explicitly noted in BFD sources:
"The ABI requires that the *LO16 immediately follow the *HI16.
However, as a GNU extension, we permit an arbitrary number of
*HI16s to be associated with a single *LO16. This significantly
simplies the relocation handling in gcc."
and has been like this since forever. The pairing is supposed to be
done by the assembler so as long it has been done correctly there's
nothing for the linker to complain about.
I see in the Debian bug report referred that this error only happens
with `gold', so I am highly suspicious that this is a `gold' bug. To
ensure all is in order would you therefore please send me the output of
`readelf -r src.o' and double-check your results with both `ld' and
`gold'?
