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

[David Blaikie]

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.

For example, our line table dumping doesn't dump the line table state
machine, just the resulting table that was generated from that state
machine.

In this instance I just wanted to check whether this code was testable -
especially if we are going to move to a situation where llvm-dwarfdump is a
more widely used tool, it seems prudent to ensure the testing is high
quality (to be honest, the current testing, as this is a test tool, has
been hit-and-miss (because it basically devolves to "checkin some known
dwarf in an object file and run that through dwarfdump to inspect the
output" - and we don't always bother with that))


> I would rather have a testing tool show me exactly what's in the object
> file,
> rather than do user-friendly transformations that hide (some part of) the
> exact contents of the file.
> (Annotating the output, which you have been doing such a great job
> on--thanks!--
> is fine; that's different from hiding things that are actually in the
> file.)
>
> It shouldn't be hard to pipe llvm-dwarfdump output through a filter that
> could
> address the ../.. part, which would still give you good comparability to
> the
> output of dwarfdump.
> Thanks,
> --paulr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140905/f6f3f63d/attachment.html>