[llvm-dev] [RFC] llvm-dwarfdump's command line interface

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Fri Sep 8 16:43:32 PDT 2017


On Fri, Sep 8, 2017 at 2:39 PM Adrian Prantl <aprantl at apple.com> wrote:

> On Sep 8, 2017, at 2:32 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Fri, Sep 8, 2017 at 2:25 PM Adrian Prantl <aprantl at apple.com> wrote:
>
>> I would like to grow llvm-dwarfdump to become a drop-in replacement for
>> the dwarfdump utility that is currently shipping on Darwin. (You can search
>> the web for "darwin dwarfdump manpage" to see the currently supported
>> feature set.)
>
>
> For anyone looking: http://www.manpagez.com/man/1/dwarfdump/
>
>
>> Doing this means implementing the missing features, such as the ability
>> to print only subsets of DIEs, looking up DIEs by name or address, and the
>> option to produce more diff-friendly output. I'm fairly certain that these
>> additional features will be beneficial on all LLVM-suported platforms.
>> To turn it into a drop-in replacement on Darwin, I will also need to
>> re-orgnize the command line interface a bit. In particular (and this is
>> pretty much the only difference)
>>
>> $ llvm-dwarfdump --debug-dump=info
>> $ llvm-dwarfdump --debug-dump=apple-objc
>>
>> becomes
>>
>> $ dwarfdump --debug-info
>> $ dwarfdump --apple-objc
>>
>> respectively.
>> My question is, how attached are users on other platforms to the current
>> command line interface?
>
>
> I'm not especially attached - though I imagine it's pretty cheap to
> support both (though I don't personally mind if you want to migrate from
> one to the other - will just take a bit to relearn the muscle memory).
>
>
> If we're looking for the path of least resistance, we could even support
> both variants as aliases at the same time, since they don't conflict.
>
> One other thing: If we're moving towards a point where llvm-dwarfdump is
> not just a tool for LLVM developers but a shipping product, might be worth
> being a bit more rigorous about testing for it (historically sometimes
> dwarfdump functionality hasn't been tested - committed along with the LLVM
> functionality it was implemented to test - or the only testing is with
> checked in object files, which are a bit hard to maintain).
>
>
> Fully agreed, and indeed with all recent patches that went into
> llvm-dwarfdump we are already moving in that direction.
>
>
There was some work this way in llvm-objdump as well :)

-eric


> Either looking at the DWARF YAML support and maybe fleshing it out a
> bit/making it more usable, or maybe assembly based tests? Not sure.
>
>
> I'm trying to figure this out right now by looking at
> https://reviews.llvm.org/D36993 ...
>
> -- adrian
>
> I could easily create a separate command line parser for Darwin that
>> mimicks Darwin dwarfdump (like llvm-objdump does), or we could just change
>> the command line interface for llvm-dwarfdump. I know that there is also a
>> dwarfdump utility on Linux (based on libdwarf?) that has an entirely
>> different command line interface from both llvm-dwarfdump and Darwin
>> dwarfdump.
>> Do people see value in keeping the llvm-dwarfdump command line interface
>> or would changing it to the above format be acceptable?
>>
>> thanks for your input!
>> Adrian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170908/dac0cdbb/attachment.html>


More information about the llvm-dev mailing list