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

[Davide Italiano via llvm-dev]

On Fri, Sep 8, 2017 at 2:32 PM, David Blaikie via llvm-dev
<llvm-dev at lists.llvm.org> 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).
>
> 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). 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.
>

In my opinion assembly-based testing is the way forward. We used this
in lld and it went a long way.
YAML I think it's fine to simulate what MC can't emit (e.g. broken
object files).
YAML IMHO, introduces an obfuscation layer (at least for me, but maybe
I spent too much time looking at object files).
Also, we found out issues with YAML when reducing testcases with
obj2yaml/yaml2obj (in particular, the mapping is not isomorphic &
loses interesting information).

Thanks,

--
Davide