RE: [committed 0/3] MIPS/GAS: R6 PC-relative relocation fixes

["Maciej W. Rozycki" <macro at imgtec dot com>]

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?

 Correct.

> 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 
consistent.

> 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).

  Maciej