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