<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 11, 2017 at 11:50 AM Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 8, 2017 at 2:32 PM, David Blaikie via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
><br>
> On Fri, Sep 8, 2017 at 2:25 PM Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br>
>><br>
>> I would like to grow llvm-dwarfdump to become a drop-in replacement for<br>
>> the dwarfdump utility that is currently shipping on Darwin. (You can search<br>
>> the web for "darwin dwarfdump manpage" to see the currently supported<br>
>> feature set.)<br>
><br>
><br>
> For anyone looking: <a href="http://www.manpagez.com/man/1/dwarfdump/" rel="noreferrer" target="_blank">http://www.manpagez.com/man/1/dwarfdump/</a><br>
><br>
>><br>
>> Doing this means implementing the missing features, such as the ability to<br>
>> print only subsets of DIEs, looking up DIEs by name or address, and the<br>
>> option to produce more diff-friendly output. I'm fairly certain that these<br>
>> additional features will be beneficial on all LLVM-suported platforms.<br>
>> To turn it into a drop-in replacement on Darwin, I will also need to<br>
>> re-orgnize the command line interface a bit. In particular (and this is<br>
>> pretty much the only difference)<br>
>><br>
>> $ llvm-dwarfdump --debug-dump=info<br>
>> $ llvm-dwarfdump --debug-dump=apple-objc<br>
>><br>
>> becomes<br>
>><br>
>> $ dwarfdump --debug-info<br>
>> $ dwarfdump --apple-objc<br>
>><br>
>> respectively.<br>
>> My question is, how attached are users on other platforms to the current<br>
>> command line interface?<br>
><br>
><br>
> I'm not especially attached - though I imagine it's pretty cheap to support<br>
> both (though I don't personally mind if you want to migrate from one to the<br>
> other - will just take a bit to relearn the muscle memory).<br>
><br>
> One other thing: If we're moving towards a point where llvm-dwarfdump is not<br>
> just a tool for LLVM developers but a shipping product, might be worth being<br>
> a bit more rigorous about testing for it (historically sometimes dwarfdump<br>
> functionality hasn't been tested - committed along with the LLVM<br>
> functionality it was implemented to test - or the only testing is with<br>
> checked in object files, which are a bit hard to maintain). Either looking<br>
> at the DWARF YAML support and maybe fleshing it out a bit/making it more<br>
> usable, or maybe assembly based tests? Not sure.<br>
><br>
<br>
In my opinion assembly-based testing is the way forward. We used this<br>
in lld and it went a long way.<br></blockquote><div><br>I think there's a few differences here:<br>lld isn't testing for invalid object input, so assembly's sufficient<br>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.<br><br>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.<br><br>So having a higher level dense textual DWARF representation would be more analogous to how lld tests are written in assembly.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
YAML I think it's fine to simulate what MC can't emit (e.g. broken<br>
object files).<br>
YAML IMHO, introduces an obfuscation layer (at least for me, but maybe<br>
I spent too much time looking at object files).<br>
Also, we found out issues with YAML when reducing testcases with<br>
obj2yaml/yaml2obj (in particular, the mapping is not isomorphic &<br>
loses interesting information).<br></blockquote><div><br>Certainly ought to be fixed.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
--<br>
Davide<br>
</blockquote></div></div>