[PATCH v2 0/2] LD: Export relative-from-absolute symbol marking to BFD
Maciej W. Rozycki
macro@mips.com
Mon Jul 16 23:58:00 GMT 2018
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.
This is v2 of the proposal, addressing issued discussed in the review
into account. OK to apply?
Maciej
More information about the Binutils
mailing list