This is the mail archive of the
mailing list for the binutils project.
RE: [committed 0/3] MIPS/GAS: R6 PC-relative relocation fixes
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Maciej Rozycki <Maciej dot Rozycki at imgtec dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 22 Jun 2016 08:56:45 +0000
- Subject: RE: [committed 0/3] MIPS/GAS: R6 PC-relative relocation fixes
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 00 dot 1606211808390 dot 7182 at tp dot orcam dot me dot uk>
Maciej Rozycki <Maciej.Rozycki@imgtec.com> writes:
> I have committed this small set of patches to address issues in GAS with
> resolved R6 PC-relative relocations. Such relocations are expected to be
> produced from certain pre-R6 code containing ISA override directives,
> however GAS terminates with assertion failures instead, which is something
> that is supposed not to happen with any user-supplied code.
Just to check. This is a case where a module is MIPS32R2 for example but
has an ISA override (.set mips32r6) and then uses a PC-relative instruction
from R6. The PC-relative relocation gets applied at assembly time if
possible because only R6 modules defer these relocations to link time.
Is that right?
I see that you fixed the inverse case where a module is mips32r6 but an
ISA override ends up meaning relocations are not retained for link time.
Thanks for all these bits of cleanup that I missed in original submission.
Personally I would have opted to just force all the new relocations to be
deferred to link time irrespective of architecture to avoid the need to
apply the fixups in the assembler but it doesn't matter. I don't think we
need to treat this special case as ABI defined as the benefit is minimal.
I.e. I don't think it needs replicating in LLVM integrated assembler.
What are your thoughts about making/not making this ABI defined behaviour?