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: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 22 Jun 2016 13:53:25 +0100
- 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> <6D39441BF12EF246A7ABCE6654B023537E456D14 at HHMAIL01 dot hh dot imgtec dot org>
On Wed, 22 Jun 2016, Matthew Fortune wrote:
> > 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.
Both the straight and the inverse case have been corrected by making them
> 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.
I actually considered forcing the generation of PC-relative relocations,
however (as seen with commit 912815f079a8 ("MIPS/GAS: Use the module level
ISA setting for R6 relaxation")) any such decision would also affect
R_MIPS_PC16, which we've had since forever, and I have concluded it'll be
best left unchanged for older ISAs first, and it'll be best to keep all
these PC-relative relocations consistent second. There's little effort
really required in the assembler to get it right. Perhaps I'll factor out
the processing of branch/LWPC/LDPC relocations even as they all follow the
same "mask & shift" pattern.
> What are your thoughts about making/not making this ABI defined behaviour?
I don't think we need or want to dictate a policy here. If a toolchain
doesn't support R6 linker relaxations, then it may well opt for avoiding
producing relocations for expressions which have been fully resolved at
the assembly time.
And there is some benefit from avoiding extraneous relocations -- some
performance gain in static link processing and also internally generated
symbols, such as with `.' or local labels, have cryptic names with control
characters embedded, which clutter output from tools like `readelf' or
`objdump' (I've seen people thinking this is a toolchain bug actually).