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

[Frédéric Riss]

> 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 <mailto: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.

Fred

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