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

[David Blaikie]

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

>
> On 05 Sep 2014, at 20:18, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
>
> 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)
>
>
> I have no idea if the configure results are available in some other form
> that the preprocessor macros in Config.h. I get your point about the
> testing, but I’m a bit at a loss about how to implement it. Especially
> considering that these will be llvm tests: the paths need to exist for
> realpath to resolve them, but the llvm tests usually embed static paths in
> the IR.
>

So realpath won't modify fictional paths like
"/foo/bar/baz/../../../snarf.txt"? Perhaps we could use a generic routine
(not sure if we can write a platform independent one) that's a bit lighter
weight & just does the basic textual operations without actually consulting
the filesystem?


>
>
> 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.
>
>
> How do you expect lit to expose the availability of the feature?
>

Lit has a general mechanism for exposing feature testing to test cases, I
can't seem to find the lit documentation for it, but you'll see in many
test cases "REQUIRES: stuff" where stuff is some feature (shell, specific
registered/enabled targets, different pointer/long int sizes, etc). What
I'm suggesting is that lit could be taught about realpath as another
feature.


> Some syntax that would skip the test if the feature is not available?
>
> Fred
>
> 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/23513db5/attachment.html>