[Bug ld/24896] [powerpc] ld can probably drop R_PPC64_UADDR64 conversion
https://sourceware.org/bugzilla/show_bug.cgi?id=24896 --- Comment #4 from Alan Modra --- Yes, st_value is not added by ppc32 ld.so because st_value is included in r_addend for STB_LOCAL symbols by ld. This goes back further than 2003, in fact to 1997. The 2003 patch you found reverted an earlier 2003 patch. We can't fix this without changing both binutils and glibc in sync. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24896] [powerpc] ld can probably drop R_PPC64_UADDR64 conversion
https://sourceware.org/bugzilla/show_bug.cgi?id=24896
--- Comment #3 from Fangrui Song ---
Thanks for the information.
* Aligned R_PPC64_UADDR64 -> R_PPC64_ADDR64 => the code is there and it
doesn't hurt anyone, so let's keep it
* Misaligned R_PPC64_ADDR64 -> R_PPC64_UADDR64 => this matters on power7 and
previous processors (assumably they may trap for a misaligned 64-bit access)
Am I correct? There is probably a bug in glibc powerpc32. For a dynamic
relocation R_PPC_UADDR32 to a STB_LOCAL STT_SECTION symbol, the relocated value
is wrong.
The offending code was added in 2003 but there seems no way for gas to emit
UADDR32, so ld won't emit dynamic UADDR32, and this bug gets unnoticed for
years...
// glibc/sysdeps/power/powerpc32/dl-machine.h
auto inline void __attribute__ ((always_inline))
elf_machine_rela (struct link_map *map, const Elf32_Rela *reloc,
const Elf32_Sym *sym, const struct r_found_version *version,
void *const reloc_addr_arg, int skip_ifunc)
{
...
/* binutils on ppc32 includes st_value in r_addend for relocations
against local symbols. */
if (__builtin_expect (ELF32_ST_BIND (sym->st_info) == STB_LOCAL, 0)
&& sym->st_shndx != SHN_UNDEF)
{
sym_map = map;
value = map->l_addr; /// st_value is not considered
}
else
{
sym_map = RESOLVE_MAP (&sym, version, r_type);
value = SYMBOL_ADDRESS (sym_map, sym, true);
}
value += reloc->r_addend;
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24896] [powerpc] ld can probably drop R_PPC64_UADDR64 conversion
https://sourceware.org/bugzilla/show_bug.cgi?id=24896 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |WONTFIX --- Comment #2 from Alan Modra --- ld selects R_PPC64_UADDR*/R_PPC64_ADDR* depending on their alignment for dynamic relocations, and glibc ld.so applies them taking into account that R_PPC64_UADDR* may not be aligned whereas all other dynamic relocs (including R_PPC64_RELATIVE) are assumed to be aligned. This mattered when we were developing the ppc64le support on power7 processors. (Yes, ppc64le was originally supported on power7 even though the hardware support for little-endian was somewhat lacking, leading to lots of alignment traps on mis-aligned memory accesses.) It's true that a strict interpretation of the relevant ABI documents would require assemblers to generate UADDR relocs in a lot more cases, but we haven't done that and I don't see any good reason to modify gas to do that now. At worst it might cause some linkers running on old hardware to take alignment traps when processing object files, slowing down the linker a little. Slightly slower tools don't matter. On power8 and later, with glibc ld.so compiled for power8, you should see the R_PPC64_UADDR* relocs being processed just like the corresponding R_PPC64_ADDR* reloc (ie. using full width memory writes rather than multiple byte writes). So there isn't much reason to avoid R_PPC64_UADDR* relocs. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24896] [powerpc] ld can probably drop R_PPC64_UADDR64 conversion
https://sourceware.org/bugzilla/show_bug.cgi?id=24896 --- Comment #1 from Fangrui Song --- Thinking more. ADDR/UADDR distinction probably makes little sense. I withdraw my proposal that teachs gas to emit UADDR. Some ld conversion rules can probably be deleted: Aligned R_PPC64_UADDR64 -> R_PPC64_ADDR64 is definitely not needed Misaligned R_PPC64_ADDR64 -> R_PPC64_UADDR64 I am not clear on this one, but I guess it probably doesn't hurt if misaligned R_PPC64_ADDR64 or R_PPC64_RELATIVE is generated, especially on powerpc64le (defaults to -mcpu=power8) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24896] [powerpc] ld can probably drop R_PPC64_UADDR64 conversion
https://sourceware.org/bugzilla/show_bug.cgi?id=24896 Fangrui Song changed: What|Removed |Added Component|gas |ld Summary|[powerpc] gas should emit |[powerpc] ld can probably |R_PPC_UADDR32/R_PPC64_UADDR |drop R_PPC64_UADDR64 |64 at unaligned locations |conversion |if the section is | |sufficiently aligned| -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
