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

[Frédéric Riss]

Would you mind if I resubmit that without the realpath code? We can then decide later how to test it. What’s your take on the getFileNameForUnit() and getFileLineInfoForCompileUnit() API move?

Thanks,
Fred

> On 05 Sep 2014, at 22:11, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> 
> On Fri, Sep 5, 2014 at 12:09 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
> 
>> On 05 Sep 2014, at 20:18, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> 
>> 
>> On Fri, Sep 5, 2014 at 12:47 AM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
>> 
>>> On 05 Sep 2014, at 00:28, David Blaikie <dblaikie at gmail.com <mailto: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 <mailto: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 <http://reviews.llvm.org/D5192>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140908/19729eda/attachment.html>