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

[Davide Italiano via llvm-dev]

On Mon, Sep 11, 2017 at 12:01 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
> On Mon, Sep 11, 2017 at 11:50 AM Davide Italiano <davide at freebsd.org> wrote:
>>
>> 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.
>
>
> I think there's a few differences here:
> lld isn't testing for invalid object input, so assembly's sufficient
> lld's mostly testing low-level object constructs, so assembly's already
> intended to be a fairly terse/legible/maintainable textual form for object
> files. This doesn't seem to scale well to DWARF, which is a format within a
> format, with no native dense textual representation.
>
> For example, when writing assembly you don't need to write the section
> headers/tables/etc - but when writing DWARF in assembly you have to create
> the headers, the abbreviations, etc, all manually.
>
> So having a higher level dense textual DWARF representation would be more
> analogous to how lld tests are written in assembly.
>

I'm not opposed to using an higher level representation, assuming it's
not too verbose.

>>
>> 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).
>
>
> Certainly ought to be fixed.
>

It its getting fixed, one bug at the time :)

> - Dave
>
>>
>>
>> Thanks,
>>
>> --
>> Davide



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare