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

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

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>

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