[PATCH] Add -bare option to llvm-objdump

[Sean Silva]

On Thu, Sep 11, 2014 at 1:30 PM, Kevin Enderby <enderby at apple.com> wrote:

>
> On Sep 11, 2014, at 1:09 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Thu, Sep 11, 2014 at 11:59 AM, Kevin Enderby <enderby at apple.com> wrote:
>
>>
>> On Sep 11, 2014, at 12:11 AM, Steve King <steve at metrokings.com> wrote:
>>
>> On Wed, Sep 10, 2014 at 8:29 PM, Sean Silva <chisophugis at gmail.com>
>> wrote:
>>
>>
>> Right, you mean like otool's -d (" Display the contents of the
>> (__DATA,__data) section") or -t ("Display  the contents of the
>> (__TEXT,__text) section.  With the -v flag, this disassembles the text.")?
>> ;)
>>
>>
>> I've never used otools, but presumably Kevin has some idea here.
>>
>>
>> I’ll try to explain my ideas.  I think what we are talking about is how
>> detailed the disassembly is, that is not printing just the raw bytes of a
>> section and no disassembly.  That is we are not talking about otool(1)’s
>> printing of the text section without the -v flag.
>>
>> Disassembly for otool(1) requires -v to get the disassembly of sections
>> with instructions in them.  In this mode (without -V) it will disassembly
>> the instructions but will not try to symbolicate the operands.  For example:
>>
>> % otool -tv hello.o
>> …
>> 0000000000000026 callq 0x2b
>>
>> With -V then it will attempt to symbolicate the operands (using all the
>> information it has, relocation entries, symbol tables, etc):
>>
>> % otool -tV hello.o
>> …
>> 0000000000000026 callq _printf
>>
>> my goal is by default this:
>>
>> % llvm-objdump -m -d hello.o
>>
>> will do the same as otool(1)’s -tV and produce the best disassembly (or
>> maybe even better).
>>
>> But I do want have the option of getting just the disassembly without
>> symbolicating operands.  So I’m thinking that these would would produce the
>> same results:
>>
>> % llvm-objdump -m -d hello.o -bare
>> % otool -tv hello.o
>>
>> with both producing disassembly but not symbolicating operands.  But I’m
>> open to other ways to get this functionality.  One note if your carefully
>> reading non-symbolic operand to the callq instruction above, I want to see
>> the the target address, in this case 0x2b, not the displacement.
>>
>
> So what is your use case?
>
>
> My use case for -v without -V is for developers like myself that have to
> debug broken binaries.  The use case for using a target address not a
> displacement is one can actually follow the flow control if the disassembly
> without knowing how each instruction works and doing the math to see where
> branches and calls go.
>

Sorry, what I mean was: what is your use case that is motivating you to
ship this tool to users? Did you literally get a user request "I want
llvm-objdump"?


>
> Are you shipping this tool to users?
>
>
> Yes otool(1) has always been shipped to users with the developer tools.
>  The hope is to ship llvm-objdump to users at some point too.
>

Shipping llvm-objdump to users puts it under a much stronger compatibility
contract than any of the other tools (except obviously the clang driver).
That along I think is enough to motivate splitting it out into a separate
tool.


>
> If you're explicitly trying to replicate otool's behavior, it seems much
> better to just make a separate tool, or look at argv[0].
>
>
> With the -m (or -macho) option for llvm-objdump to "Use MachO specific
> object file parser” I’m hoping to replicate otool(1)’s behavior but in the
> clang tree so all can use and improve it.
>

I think it would make more sense to make a separate tool that does exactly
what you want, so that you don't have to bother users with -m or anything.
What code, if any, are you sharing with the rest of llvm-objdump?

-- Sean Silva


>
>
> -- Sean Silva
>
>
>
>>
>>
>> What is your goal?
>>
>>
>> A symbolizing disassembler with at least the possibility to tune
>> output to match existing norms per host platform.
>>
>>
>> From what I can gather, it seems like you just want to
>> make llvm-objdump's default behavior match GNU objdump, which doesn't seem
>> like a very good direction (how deep is the rabbit hole? why GNU objdump
>> and
>> not tool or the windows one?).
>>
>>
>> What I personally need is a just symbolizing disassembler.  What my
>> colleagues will expect is a fair approximation of GNU objdump because
>> that's what they already know.  Kevin piped up early that he wanted
>> otools style output, so we ended up at the goal above.
>>
>>
>> Yep my goal would be the best symbolic disassembly by default.  With
>> switches to turn off the symbolic operands for test cases or the power user
>> who is likely the guy hunting down bugs and needs to see the operands raw.
>>  Basically it would be nice to have a less verbose option for those that
>> need these things.
>>
>> For example, the code I added for the Mach-O printing of private headers
>> has a boolean verbose and will do this today.  The call right now is
>> passing in true for verbose but if there was a -bare or some other option
>> I’d wire it up to that parameter.  I don’t really care what we call it and
>> I can live with what ever develops over time.  If nothing does I’ll
>> eventually create a Mach-O specific option to wire this up.
>>
>> My thoughts,
>> Kev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140911/4060db97/attachment.html>