https://sourceware.org/bugzilla/show_bug.cgi?id=32624
Bug ID: 32624
Summary: broken heuristics in R_386_GOT32{,X} handling
Product: binutils
Version: 2.45 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: jbeulich at suse dot com
Target Milestone: ---
Where in the psABI is all the special casing spelled out that was implemented
in the context of pr20244, pr21168, and pr21285? Since it's not documented
anywhere what the @got modifier does in assembly, some special casing there may
still be okay. Yet most of this lives in the linker. And the logic there easily
breaks in both directions:
When
lea sym@got, %eax
is okay even in PIC code (and is special-treated), why is
lea sym@got(,%eiz), %eax
not having the exact same treatment?
Why is
vpermb sym@got, %zmm1, %zmm0
treated as if it was LEA?
When
.long 0x058d058d, sym@got
is accepted in PIC, why would
.long 0x058c058c, sym@got
.long sym+0x05000000, sym@got
not be? Or the other way around.
As Cary did point out in pr21285, all of this can only validly be handled with
distinct relocation types. Looking backwards from where the relocation is to be
applied simply is impossible to do reliably on x86.
Looking at from where all of this has started: While at the source level in
lea sym@got, %eax
sym@got may indeed mean something else than the same construct in
mov sym@got, %eax
(pending documentation on what @got actually means in which context; without
that it may as well be - and would be more natural - that the construct means
the same in both contexts) that difference then needs expressing by using
distinct relocations. As it stands, the linker may - for PIC - emit errors in
an unpredictable fashion, and it may silently produce broken code. All of which
as a result of R_386_GOT32{,X} not really following what the psABI mandates for
them. (Where is an up-to-date version of the psABI, btw? All I can find is the
now almost 30 years old SCO copy.)
To preempt an argument along the lines of "this works for most cases" - no, the
linker needs to work reliably everywhere, under all circumstances.
--
You are receiving this mail because:
You are on the CC list for the bug.
