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

[David Blaikie via llvm-dev]

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.


> 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.

- Dave


>
> Thanks,
>
> --
> Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170911/75873c92/attachment.html>