[PATCH 0/3] MIPS/LD: Fix high-part relocations in PIC code with absolute symbols

["Maciej W. Rozycki" <macro at linux-mips dot org>]

Hi,

 I have recently tried to build a piece of firmware (Broadcom CFE, for the 
SWARM board) that links as PIC code, so that it can move itself around in 
memory.

 That has failed, relying on LD accepting an R_MIPS_HI16/R_MIPS_LO16 
relocation pair against an absolute symbol, which no longer happens as 
from commit 861fb55ab50a ("Defer allocation of R_MIPS_REL32 GOT slots"), 
<https://sourceware.org/ml/binutils/2008-08/msg00096.html>.  I could not 
find an easy way around it and absolute symbols are conceptually deferred 
link-time constants, so I have decided to correct LD instead and make it 
accept R_MIPS_HI16 and similar relocations even in PIC code as long as the 
symbol referred is absolute (R_MIPS_26, etc. are still not accepted, as 
their run-time calculation is not position-independent).

 This turned out to be a simple change, however I decided to take the 
opportunity to switch to using `->einfo' rather than `_bfd_error_handler' 
for error reporting here, so that location details are provided about the 
relocation complained about and any further link issues are also reported 
rather than just the first one, so that they can all be observed at once 
eliminating the need to discover them iteratively.  Then verification 
revealed an inconsistency in error message composition, analogous to one 
previously addressed with commit 174d0a74a2e6 ("PowerPC/BFD: Convert `%P: 
%H:' to `%H:' in error messages").

 Hence I made this a small patch series, including 1/3 as a preparatory 
change that requires a general maintainer's approval as it applies to 
generic linker code.  I'll commit 2/3 and 3/3 once 1/3 has been approved.

 See individual change descriptions for further details.  I have 
regression-tested these changes against my usual targets with no problems 
observed (i.e. sadly this is not covered anywhere).

  Maciej