[Bug gas/32624] New: broken heuristics in R_386_GOT32{,X} handling

[jbeulich at suse dot com]

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.