[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 11:49:21 PDT 2017

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

More information about the llvm-dev mailing list