This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/77300] [MIPS] incorrectly moves instruction containing local GOT16 relocation into a delay slot


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77300

Maciej W. Rozycki <macro@linux-mips.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro@linux-mips.org

--- Comment #2 from Maciej W. Rozycki <macro@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'?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]