[PATCH 0/2] LD: Export relative-from-absolute symbol marking to BFD

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

Hi,

 In the course of addressing PR ld/21375 I came across a need to be able 
to tell absolute and ordinary symbols apart and realised that the target 
BFD backend does not have access to necessary symbol data.

 The thing is for the fix to PR ld/21375 to work the MIPS backend has to 
assign absolute symbols to the global rather than local part of the GOT 
(assigning to the local GOT part implies load-time relocation by the base 
address in the MIPS psABI, which is of course not appropriate for an 
absolute symbol), and the assignment happens in `mips_elf_lay_out_got' at 
the time `->elf_backend_size_dynamic_sections' is called.  Determining 
whether a symbol is absolute usually works by checking whether the section 
that owns the symbol is absolute or not, however not for ordinary symbols 
defined in a linker script outside an output section statement.

 Such symbols are initially defined as absolute and are owned by the 
absolute section and then only converted to section-relative ones and 
assigned to their ultimate sections in the final phase of the link.  Such 
symbols have to be treated as any other ordinary symbols.  However the 
target BFD backend has no way to identify these symbols as the relevant 
information is only carried in the defining assignment expression on the 
linker's side.

 This has triggered as an issue with the special `__ehdr_start' symbol, 
which got assigned to the global GOT part as absolute and then turned out 
ordinary requiring to go into the local GOT part due to being local.  
Consequently the MIPS backend had but to give up and bail out facing the 
inconsistency.

 This small patch series comprises a change to make the necessary 
information available for BFD and then a proposed update for a couple of 
backends, which by visual code inspection I believe that ought to use it.  
See the individual descriptions for further details.

 Only the first change is required for PR ld/21375, so we can discuss the 
other part without blocking the fix for said PR, and I'll be posting that 
fix shortly for a reference in case it helps with the review here.

 No regressions against my usual targets.  OK to apply?

  Maciej