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

[Robinson, Paul]

> > 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 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