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

[David Blaikie]

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

>
> On 05 Sep 2014, at 00:28, David Blaikie <dblaikie at gmail.com> wrote:
>
> Please go ahead & commit the decl/call_line portion of this (I'll take
> your word for it that these seem like the only ones that should be printed
> as decimal, the rest as hex - and if we see other cases we can figure it
> out at that point) & then rebase this patch.
>
>
> This is r217232, thanks.
>
> 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?).
>

Is that configure property available to lit, so we could write tests that
demonstrate that the functionality is actually working when the feature is
available? (specifically by comparing the line table entry (which will
still have the ../../../ stuff) and the processed name in the DIE dump) (&
demonstrate that, in the absence of the feature, we get the (degraded)
expected/correct output too)

Might be worth adding it as a feature in lit - so far as I understand it's
not too expensive to do so. NOt sure if you have to plumb a separate
negative feature through so you can write tests targeted for platforms that
lack the feature separately.


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

That might be worthwhile.


> 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.
>
> Fred
>
>
> On Thu, Sep 4, 2014 at 2:37 PM, Frederic Riss <friss at apple.com> wrote:
>
>> Sorry for the spam. I'm still learning to use arcanist, and I must say at
>> this point it's more a burden that a help... This latest revision is the
>> result of a small series of 3 commits that should be easy enough to
>> distinguish. They aren't really intermingled except for the test updates.
>> The first just prints the line numbers in decimal and updates the tests.
>> The second moves some static helpers of DWARFContext.cpp into equivalent
>> methods of LineTable. There should be no functional change though.
>> The third one uses the newly exposed method to find and print full names
>> for files referenced by DW_AT_(decl|call)_file.
>>
>> http://reviews.llvm.org/D5192
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140905/9bd53df2/attachment.html>