[llvm-dev] [RFC] llvm-dwarfdump's command line interface (original) (raw)

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 11 12:10:56 PDT 2017

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

More information about the llvm-dev mailing list