https://sourceware.org/bugzilla/show_bug.cgi?id=32591
Bug ID: 32591
Summary: undue GOTPCREL relaxation attempts
Product: binutils
Version: 2.45 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
LD appears to assume that @gotpcrel can only be used in small model or x32
code, building upon addresses of resolved symbols being within the low 4Gb (or
within ±2Gb for PIC code). Relocation overflows can result otherwise, which the
linker then converts to the suggestion to use --no-relax.
That suggestion has two problems: For one I think the linker ought to work
correctly and reliably without special command line options. And then
--no-relax suppresses more of the relaxation than strictly necessary: For the
specific purpose of building the Xen hypervisor we'd want the (PIC-specific)
MOV->LEA transformation (no issue with the resulting PC-relative relocations),
but we'd need to avoid the memory operand -> immediate operand conversions
resulting in relocation overflows, for using absolute relocs. These overflows
are simply a result of us linking the binary to a base address in the upper
half of address space. And no, linking with -shared or -pie is not an option,
for the linker then refusing to process other relocations that we use
(R_X86_64_32 in particular).
The main problem appears to be that at the time the decision is taken whether
to relax certain insns (and into which alternative forms), we don't know yet
whether the replacement relocs would end up overflowing. Thus, unless the whole
determination can be moved (much?) later, the only choice would look to be to
undo the transformations (perhaps just partly, i.e. after initially converting
to MOV-from-immediate, replace that by the less restrictive RIP-relative LEA;
nothing similar is of course possible for arithmetic insns we convert). Which
would of course require there to be enough information to restore what had been
there originally (I haven't thoroughly checked yet whether that's the case).
--
You are receiving this mail because:
You are on the CC list for the bug.
