https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |segher at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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
section.
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)?
but
