[PATCH] [dwarfdump] Implement extraction of file information referenced in .debug_info.

[David Blaikie]

On Fri, Sep 5, 2014 at 11:56 AM, Frédéric Riss <friss at apple.com> wrote:

>
> On 05 Sep 2014, at 20:05, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
>
> On Fri, Sep 5, 2014 at 10:39 AM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> wrote:
>
>> > > The realpath piece of this is particularly interesting - I don't know
>> > > what that API is, where it comes from (why it might not always be
>> > > available), etc. Also, not sure it makes sense to canonicalize the
>> paths
>> > > based on the actual filesystem, rather than just rendering what's in
>> the
>> > > line table... maybe some examples would help me understand better. (is
>> > > that codepath tested? How do we test it on machines that don't have
>> > > realpath?)
>> >
>> > I knew this bit would attract some interest. Regarding the availability,
>> > there is a configure test, thus I suppose it’s not available everywhere
>> > (Windows maybe?). It really helps the legibility when you have projects
>> with
>> > deep, recursive, build trees. For example, instead of
>> >
>> >
>> "/tmp/build/some/project/with/very/deep/source/tree/../../../../../../../../some/project/with/very/deep/source/tree/foo.c”
>> >
>> > you get
>> >
>> > “/tmp/some/project/with/very/deep/source/tree/foo.c"
>> >
>> > Note however that this part is optional and could be discussed
>> separately.
>> > Another motivation for me to have this in llvm-dwarfdump is that
>> Darwin’s
>> > dwarfdump does this transformation. You might not care, but having
>> nearly
>> > identical outputs allows me to cross-verify the 2 implementations on a
>> very
>> > large set of archived binaries. I think this gets us more coverage that
>> any
>> > LIT tests that we might add. I understand however that this is in no
>> way a
>> > strong argument for getting it into the tree, I just thought I’d
>> mention the
>> > validation I do on the side.
>>
>> My understanding is that llvm-dwarfdump is a tool to help testing LLVM,
>> while
>> Darwin's dwarfdump is a tool to help users understand their object files.
>>
>
> I don't think the use cases are so distinct. Most of the people who care
> about the exact DWARF that's produced either work on debug info producers
> (probably LLVM, in this instance) or consumers, and most of the time ease
> of reading the semantics expressed by the debug info is sufficient.
>
>
> I totally agree with that point of view. I also can understand Paul’s
> opinion. Nothing prevents us from having a —verbose or —raw option that
> avoids all the shortcuts and displays the naked debug info. But again, be
> it for testing or human consumption, I think the prettified output is
> (nearly always) better.
>

Agreed - even for the existing line table situation, I think I'm going to
run up against a need to dump the actual state machine eventually. But
we'll cross that bridge when we come to it - and add pieces of "raw" output
mode as we need them.


>
> Fred
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140905/1e5e3206/attachment.html>