Jakub Jelinek <jakub at gcc dot> changed:

           What    |Removed                     |Added
                 CC|                            |amodra at gcc dot,
                   |                            |jakub at gcc dot,
                   |                            |segher at gcc dot

--- Comment #7 from Jakub Jelinek <jakub at gcc dot> ---
Wonder why we are treating this as a regression rather than a missing feature.
powerpc64-linux-gnu has just a very weird way of handling symbols.
readelf -Wa btest says for the test3 stuff:
  [21] .opd              PROGBITS        0000000010020018 010018 000808 00  WA 
0   0  8
    34: 00000000100200a8  1048 FUNC    LOCAL  DEFAULT   21 f23.constprop.1
    35: 00000000100200c0    52 FUNC    LOCAL  DEFAULT   21 f22.constprop.0
    36: 00000000100200d8    52 FUNC    LOCAL  DEFAULT   21 test3
and objdump -s -j .opd btest:
 100200a8 00000000 10001700 00000000 10028900  ................
 100200b8 00000000 00000000 00000000 10001b20  ............... 
 100200c8 00000000 10028900 00000000 00000000  ................
 100200d8 00000000 10001b60 00000000 10028900  .......`........
 100200e8 00000000 00000000 00000000 10001ba0  ................
which means the f23.constprop.1 function descriptor is at 0x100200a8 (.text
address, .toc pointer and if needed static chain data), and the actual function
starts at 0x10001700 with length of 1048 bytes.  objdump -dr btest shows:
0000000010001700 <.f23.constprop.1>:
    10001700:   7c 08 02 a6     mflr    r0
    10001704:   fb a1 ff e8     std     r29,-24(r1)
    10001b10:   00 00 00 01     .long 0x1
    10001b14:   80 0e 00 00     lwz     r0,0(r14)
    10001b18:   60 00 00 00     nop
    10001b1c:   60 00 00 00     nop

0000000010001b20 <.f22.constprop.0>:
    10001b20:   7c 08 02 a6     mflr    r0
but the symbol table actually doesn't have any .f23.constprop.1 or
.f22.constprop.0 or .test3 symbols (in the distant past it used to contain them
though I think).

Now, the reason why objdump shows something is the
ppc64_elf_get_synthetic_symtab function in bfd/ that creates these synthetic
symbols.  If we want the test to pass, I guess we would need to synthetize
these symbols too, or if we are always just looking at the .text symbols just
replace them.

So, I guess for EM_PPC64 (how to determine what is ELFv2 and what is the old
stuff?), read the .opd section and remember it somewhere, similarly record
somewhere the section index for it and base address, and then in
elf_initialize_syminfo for symbols with sym->st_shndx pointing to the .opd
section instead of
      elf_symbols[j].address = sym->st_value + base_address;
read the quadword at (sym->st_value - opd_base) offset from the start of .opd
Or shall we instead have elf_initialize_syminfo_ppc64, the function isn't that
long, which would be used for ppc64 and would be passed the additional data
from elf_add (.opd section data pointer, address and section index)?

Reply via email to