rdar://30143243: otool fails to disassemble whole binary

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

14-Feb-2017: Me

Changed the Rank to Medium as even though the output of llvm-objdump is not as "nice" as the one from otool (personal preference I guess), it works as a work-around when otool fails.

By m.hanauska at Feb. 14, 2017, 10:36 a.m. (reply...)

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 where otool does, it starts disassembling at the start of the text section, just like otool-classic does. So already that was a untrue. It is not the truth that
llvm-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 than otool-classic or any other otool 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 of otool. otool is just behaving wrong and that is definitely not the fault of llvm-objdump. Please re-open that bug and fix otool. So far all you did was making false accusation to the llvm community but if otool misbehaves, than this is your mistake as you are in control how otool shall behave.

By m.hanauska at Feb. 14, 2017, 10:36 a.m. (reply...)

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!

By m.hanauska at Jan. 25, 2017, 9:46 a.m. (reply...)

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.

By m.hanauska at Jan. 25, 2017, 9:09 a.m. (reply...)

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!

Open Radar