readelf -r dumps RELR relocations while objdump -R doesn't. Should objdump -R dump RELR as well? % readelf -W -r a Relocation section '.rela.dyn' at offset 0x588 contains 5 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000003fc0 0000000100000006 R_X86_64_GLOB_DAT 0000000000000000 __libc_start_main@GLIBC_2.34 + 0 0000000000003fc8 0000000300000006 R_X86_64_GLOB_DAT 0000000000000000 _ITM_deregisterTMCloneTable + 0 0000000000003fd0 0000000500000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0 0000000000003fd8 0000000600000006 R_X86_64_GLOB_DAT 0000000000000000 _ITM_registerTMCloneTable + 0 0000000000003fe0 0000000700000006 R_X86_64_GLOB_DAT 0000000000000000 __cxa_finalize@GLIBC_2.2.5 + 0 Relocation section '.rela.plt' at offset 0x600 contains 2 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000004000 0000000200000007 R_X86_64_JUMP_SLOT 0000000000000000 __errno_location@GLIBC_2.2.5 + 0 0000000000004008 0000000400000007 R_X86_64_JUMP_SLOT 0000000000000000 printf@GLIBC_2.2.5 + 0 Relocation section '.relr.dyn' at offset 0x630 contains 3 entries which relocate 4 locations: Index: Entry Address Symbolic Address 0000: 0000000000003da0 0000000000003da0 .init_array 0001: 0000000000000003 0000000000003da8 .fini_array 0002: 0000000000030001 0000000000004018 __dso_handle 0000000000004020 xxx % objdump -R a a: file format elf64-x86-64 DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 0000000000003fc0 R_X86_64_GLOB_DAT __libc_start_main@GLIBC_2.34 0000000000003fc8 R_X86_64_GLOB_DAT _ITM_deregisterTMCloneTable@Base 0000000000003fd0 R_X86_64_GLOB_DAT __gmon_start__@Base 0000000000003fd8 R_X86_64_GLOB_DAT _ITM_registerTMCloneTable@Base 0000000000003fe0 R_X86_64_GLOB_DAT __cxa_finalize@GLIBC_2.2.5 0000000000004000 R_X86_64_JUMP_SLOT __errno_location@GLIBC_2.2.5 0000000000004008 R_X86_64_JUMP_SLOT printf@GLIBC_2.2.5
Hi MaskRay, Ehh, I am in two minds about this. On the one hand, it would make sense for objdump to display all of the relocation sections when it is asked to, rather than just ignoring the SHT_RELR sections. On the other hand, we already have readelf doing this and adding more code to the binutils just means adding more potential bugs. I basically see two approaches to solving this issue. Either 1) have objdump issue a message along the lines of "section XXX contains RELR formatted relocs which are not supported by objdump" or 2) move readelf's code for dumping RELR relocs into a separate file which can then be used by both readelf and objdump. I like 1) for its simplicity and 2) for its give-the-user-all-the-support-we-can approach. Do you have a preference ? Cheers Nick
Hi Nick, Sorry for my late reply and happy new year! I favor 1) for its simplicity. I do think it's tricky to share code between readelf (no BFD dependency) and objdump. It's probably good enough to encourage users to use readelf -r more.
Created attachment 15874 [details] Proposed patch Hi Maskray, OK, what do you think of this patch ? With the patch applied, if you try to dump the relocs in a dynamic executable you get something like this: $ objdump -r /usr/bin/ls /usr/bin/ls: file format elf64-x86-64 /usr/bin/ls: This file does not contain any ordinary relocations. /usr/bin/ls: It does however contain dynamic relocations. These can be displayed with the -R option /usr/bin/ls: It does however contain RELR relocations. These can be displayed by the readelf program I was not sure what should happen if -R is used instead, since that is documented as only dumping "dynamic" relocs. So this patch does not change the behaviour for -R. Maybe we should detect if RELR relocs are present however and, after dumping the dynamic relocs, also mention that the RELR relocs are present but not displayed. What do you think ? Cheers Nick
Sorry again for the late reply. Since objdump -r ignores dynamic relocations, I think it is consistent to not report a warning when .relr.dyn is present. % objdump -r /bin/ls /bin/ls: file format elf64-x86-64 For -R, objdump -R can give a short message like .relr.dyn contains RELR relocations, which can be displayed with readelf -r. The short message implies that objdump doesn't support displaying them.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c619e92beb0784775552abe64d9a886a8cdc7236 commit c619e92beb0784775552abe64d9a886a8cdc7236 Author: Nick Clifton <nickc@redhat.com> Date: Mon Feb 24 13:44:45 2025 +0000 objdump: Inform users if RELR relocs are present in a file when using the -r or -R options and no regular relocs are present. PR 32459
OK, so I have checked in a simplified version of the patch which only issues an information message when RELR relocs are present and other relocs are not. It also does not change the behaviour when using -r and dynamic relocs are present, or vice versa.
fixed
Reopen
Created attachment 15975 [details] A patch [hjl@gnu-tgl-3 pr32459]$ readelf -r x.so Relocation section '.rela.dyn' at offset 0x1078 contains 2 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000003008 000100000001 R_X86_64_64 0000000000000000 data1 + 0 000000003018 000100000001 R_X86_64_64 0000000000000000 data1 + 0 Relocation section '.rela.plt' at offset 0x10a8 contains 1 entry: Offset Info Type Sym. Value Sym. Name + Addend 000000003000 000200000007 R_X86_64_JUMP_SLO 0000000000000000 func1 + 1e0 Relocation section '.relr.dyn' at offset 0x10c0 contains 2 entries which relocate 3 locations: Index: Entry Address Symbolic Address 0000: 0000000000002fe0 0000000000002fe0 .got 0001: 0000000000000141 0000000000003010 .bar + 0x8 0000000000003020 .foo + 0x8 [hjl@gnu-tgl-3 pr32459]$ ./objdump -R x.so x.so: file format elf64-x86-64 DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 0000000000003008 R_X86_64_64 data1 0000000000003018 R_X86_64_64 data1 0000000000003000 R_X86_64_JUMP_SLOT func1+0x00000000000001e0 0000000000002fe0 R_X86_64_RELATIVE *ABS* 0000000000003010 R_X86_64_RELATIVE *ABS* 0000000000003020 R_X86_64_RELATIVE *ABS* [hjl@gnu-tgl-3 pr32459]$
(In reply to H.J. Lu from comment #9) > Created attachment 15975 [details] > A patch Hi H.J. Well this is a nice idea, but it also raises the issue I pointed out in comment #1. Code like this makes the BFD library even more complicated than it already is, and all for a feature that is already available in the readelf program. Do we really need two different tools for displaying RELR relocations ? Cheers Nick
The BFD library provides: 1. bfd_get_dynamic_reloc_upper_bound to count dynamic relocations. 2. bfd_canonicalize_dynamic_reloc to retrieve dynamic reloctions. But they don't include RELR relocations. One symptom is that "objdump -R" doesn't display RELR relocations.
(In reply to H.J. Lu from comment #11) > The BFD library provides: > > 1. bfd_get_dynamic_reloc_upper_bound to count dynamic relocations. > 2. bfd_canonicalize_dynamic_reloc to retrieve dynamic reloctions. > > But they don't include RELR relocations. One symptom is that > "objdump -R" doesn't display RELR relocations. A patch is posted at https://sourceware.org/pipermail/binutils/2025-February/139696.html