otool fails to disassemble whole binary
Originator: | m.hanauska | ||
Number: | rdar://30143243 | Date Originated: | 23-Jan-2017 |
Status: | Open | Resolved: | 25-Jan-2017 |
Product: | Developer Tools | Product Version: | Xcode 8.2.1 |
Classification: | Serious Bug | Reproducible: | Always |
Summary: Using otool from Xcode 8.2.1, it starts disassembling from the first known symbol in the text section to the end of the text section. Everything above that symbol is ignored. Using otool from Xcode 7.3.1, it starts disassembling from the beginning of the text section to the first known symbol.Everything after that symbol is ignored. IMHO both is wrong. Steps to Reproduce: Run the following command on any binary with some symbols but also lots of stripped code: otool -tvV binary Expected Results: The whole text section is disassembled, always. In my case it starts at address 0x100002100 and ends at address 0x1003a9c97: # otool -t binary binary: Contents of (__TEXT,__text) section 0000000100002100 55 48 89 e5 41 56 53 48 8b 35 32 24 54 00 4c 8b : 00000001003a9c90 5d 41 5e 41 5f 5d c3 Actual Results: Using otool in Xcode 8: # otool -tvV binary binary: (__TEXT,__text) section _symbol_1: 00000001003a32ce pushq %rbp : 00000001003a9c96 retq Using otool in Xcode 7: (__TEXT,__text) section 0000000100002100 pushq %rbp : 00000001003a9c96 retq Both wrong. Both only disassemble a subrange of the text section and both not even the same one. Version: Xcode 8.2.1 / Xcode 7.3.1
Comments
Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!
14-Feb-2017: Me
Changed the Rank to Medium as even though the output of
llvm-objdump
is not as "nice" as the one fromotool
(personal preference I guess), it works as a work-around whenotool
fails.26-Jan-2017: Me
Okay, the "community" basically says you are a liar. Sorry, not trying to insult you here but that's what I've been told.
First of all,
llvm-objdump -disassemble
does not start disassembling whereotool
does, it starts disassembling at the start of the text section, just likeotool-classic
does. So already that was a untrue. It is not the truth thatllvm-objdump
only starts disassembling at the first known symbol.xcrun llvm-objdump -disassemble binary:
Disassembly of section __TEXT,text: text: 100002100: 55 pushq %rbp :
100002100 is the start of the text section and there is no symbol anywhere near it!
Second there is a
llvm-objdump -disassemble-all
, that really disassembles the whole text section, from the first to the last byte and that is even more thanotool-classic
or any otherotool
version has ever disassembled. So all you would have to do is to just that option if you want all the disassembly.To summarize above: No behavior of
llvm-objdump
explains the odd behavior ofotool
.otool
is just behaving wrong and that is definitely not the fault ofllvm-objdump
. Please re-open that bug and fixotool
. So far all you did was making false accusation to the llvm community but ifotool
misbehaves, than this is your mistake as you are in control howotool
shall behave.25-Jan-2017: Me
1) I filed a LLVM bug, since if you point with your finger to LLVM and claim it's their fault, let's see what "the community" has to say about that if they are willing to take the buck here: https://llvm.org/bugs/show_bug.cgi?id=31752
2) I disagree your resolution. This bug is not about the behavior of llvm-objdump, it is about the behavior of otool and otool is not a tool from LLVM. Might be that the current behavior of llvm-objdump is the way you described it, may be that this behavior is by intention and desired. Fine. But this is about the behavior of otool and as you can see by the existence of this bug, this behavior is not desired for otool. I wouldn't know any reason why it was. It is your decisions to base otool on llvm-objdump, nobody forces you to do that, correct? Okay, then change that. If llvm-objdump cannot produce the correct output, use something else that can. You cannot hide a misbehavior of one of your tools behind the misbehavior of another tool if you yourself are responsible for choosing that second tool in the first place. That is illogical, it makes no sense whatsoever. Please go and fix otool!
25-Jan-2017: Apple Developer Relations
Engineering has determined that this issue behaves as intended based on the following information:
The implementation of otool(1) changed in Xcode 8 to be based on llvm-objdump(1) from the old otool-classic(1), which is still on the system.
For the llvm community, the current behavior of starting disassembly from the first known symbol is the behavior the llvm community desires.