[PATCH] Add -bare option to llvm-objdump

[Sean Silva]

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? Are you shipping this tool to users? 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].

-- 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/c0b6141a/attachment.html>