Description of problem: When disassembling a binary compiled with full RELRO flags using objdump, the symbols refer to tables rather than the actual symbol. This makes analysis hard. Given the following program: #include <stdio.h> int main(void) { printf("Hello World\n"); return 0; } When compiled with CFLAGS=-g -DPIE -fPIE, you get: 0000000000400526 <main>: 400526: 55 push %rbp 400527: 48 89 e5 mov %rsp,%rbp 40052a: bf d0 05 40 00 mov $0x4005d0,%edi 40052f: e8 cc fe ff ff callq 400400 <puts@plt> *** OK *** 400534: b8 00 00 00 00 mov $0x0,%eax 400539: 5d pop %rbp 40053a: c3 retq 40053b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) Now when compiled with CFLAGS=-g -DPIE -fPIE -Wl,-z,relro -Wl,-z,now 0000000000400516 <main>: 400516: 55 push %rbp 400517: 48 89 e5 mov %rsp,%rbp 40051a: 48 8d 3d 9f 00 00 00 lea 0x9f(%rip),%rdi # 4005c0 <__dso_handle+0x8> 400521: e8 da fe ff ff callq 400400 <_init+0x30> *** Huh? *** 400526: b8 00 00 00 00 mov $0x0,%eax 40052b: 5d pop %rbp 40052c: c3 retq 40052d: 0f 1f 00 nopl (%rax) The second one refers to init+0x30 which is not user friendly. Version-Release number of selected component (if applicable): binutils-2.26.1-1.fc24.x86_64
Just a quick note - the problem here is that objdump does not apply dynamic relocations before running the disassembly. This could be done, it just needs more code being added to objdump.
binutils-2.27-11.fc26.rpm contains a patch to improve objdump's output in this sceanrio. It will now display: 0000000000400516 <main>: 400516: 55 push %rbp 400517: 48 89 e5 mov %rsp,%rbp 40051a: 48 8d 3d 9f 00 00 00 lea 0x9f(%rip),%rdi # 4005c0 <__dso_handle+0x8> 400521: e8 da fe ff ff callq 400400 <.plt.got> 400526: b8 00 00 00 00 mov $0x0,%eax 40052b: 5d pop %rbp 40052c: c3 retq 40052d: 0f 1f 00 nopl (%rax) for the disassembly of main, showing that the CALLQ instruction goes into the .plt.got section. In addition the contents of the .plt.got section are now disassembled as: 0000000000400400 <.plt.got>: 400400: ff 25 e2 0b 20 00 jmpq *0x200be2(%rip) # 600fe8 <puts.5> 400406: 66 90 xchg %ax,%ax 400408: ff 25 e2 0b 20 00 jmpq *0x200be2(%rip) # 600ff0 <__libc_start_main.5> 40040e: 66 90 xchg %ax,%ax 400410: ff 25 e2 0b 20 00 jmpq *0x200be2(%rip) # 600ff8 <__gmon_start__> 400416: 66 90 xchg %ax,%ax So that the jump to the PUTS function can be seen. I hope that this is sufficient. Cheers Nick
Thanks for helping to make this more usable. But any chance it could finish the resolving to point out the ultimate function being called? 400521: e8 da fe ff ff callq 400400 <puts> Just asking. I'm hoping the resolution is more complete because of scripts that are looking for certain information.
Hi Steve, > But any chance it could finish > the resolving to point out the ultimate function being called? > > 400521: e8 da fe ff ff callq 400400 <puts> I probably could do it, but I am loath to do so because it is inaccurate. We are dealing with assembler here, which is very low-level stuff. There is no such symbol as puts (in this executable), so claiming that the call instruction references it is wrong. Adding some extra annotation to the output, such as: 400521: e8 da fe ff ff callq 400400 <.plt.got> [slot 0: puts] might be possible, but it seems fragile to me, and quite likely to be a source of future bugs. I would much rather keep things simple if I can... Is it hard to modify the scripts you are using to follow the link into the PLT section manually ? Cheers Nick
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days