[PATCH] [dwarfdump] Print the name for referenced specification of abstract_origin DIEs.

[Frédéric Riss]

> On Oct 3, 2014, at 4:40 PM, Adrian Prantl <aprantl at apple.com> wrote:
> 
> 
>> On Oct 3, 2014, at 4:33 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>> On Fri, Oct 3, 2014 at 4:08 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>> 
>>> On Oct 3, 2014, at 4:06 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Oct 3, 2014 at 3:58 PM, Frederic Riss <friss at apple.com> wrote:
>>>> 
>>>> ================
>>>> Comment at: test/DebugInfo/Inputs/gmlt.ll:46
>>>> @@ -45,3 +45,3 @@
>>>> 
>>>> -; CHECK: [[F3_ABS_DEF:.*]]:  DW_TAG_subprogram
>>>> +; CHECK: DW_TAG_subprogram
>>>> ; CHECK-NEXT:     DW_AT_name {{.*}} "f3"
>>>> ----------------
>>>> dblaikie wrote:
>>>>> Not sure - might even be worth dropping these abstract subprograms
>>>>> entirely when they're not checking anything interesting (just the name is
>>>>> being checked by the abstract_definition check you modified below). *shrug*
>>>>> dunno.
>>>> Unfortunately, in some test cases they have to stay because they 'consume'
>>>> a part of the file. If I had removed this one, then the next TAG_subprogram
>>>> would match the abstract DIE and the test would fail. This is one of the
>>>> biggest shortcomings of testing the Dwarf contents with FileCheck IMHO.
>>> 
>>> 
>>> Agreed - usually the way I do this is just to skip over the unintersting
>>> tags as quickly as possible (you'll see a few test cases that just hawe
>>> "CHECK: DW_TAG_subprogram" three times in a row, etc). Open to ideas on the
>>> best way to do that. Perhaps they sometimes merit comments, or not, perhaps
>>> sometimes they could just be a "CHECK: DW_TAG" to even more opaquely skip
>>> over uninteresting tags.
>>> 
>>> 
>>> At some point it might make sense to either make llvm-dwardump also emit a
>>> syntax that is more amenable to FileCheck (one TAG per line), or the other
>>> way round.
>>> 
>> 
>> Seems reasonable. Each child gets a line? Probably wouldn't want it
>> for anything but machine based consumption, but it could be handy.
> 
> Oh yeah, I was imagining a flag that is only used when piping the output into FileCheck. The exact behavior is a bit tricky, because the dwarf tree is arbitrarily nested. Maybe have each leaf being output on a line of its own.

Yeah, the nesting part is ugly.

> Another option is to implement some of Darwin dwarfdump’s filtering options, so we could ask llvm-dwarfdump to only emit the debug info for “foo” and, e.g., all of its parents and then match only that output, and maybe have several dwarfdump invocations per test case.

I think could really help testing in some cases. I have the feeling that limiting the scope of the dump to a selected subtree could sometimes avoid the exact issue I mentioned above.

Fred

> -- adrian
>> 
>> -eric
>> 
>>> -- adrian
>>> 
>>> 
>>>> 
>>>> 
>>>> ================
>>>> Comment at: test/DebugInfo/X86/inline-member-function.ll:24
>>>> @@ +23,3 @@
>>>> +; CHECK: DW_AT_specification {{.*}} "_ZN3foo4funcEi"
>>>> +; CHECK-NOT: NULL
>>>> +; CHECK-NOT: TAG
>>>> ----------------
>>>> dblaikie wrote:
>>>>> Could write this as {{NULL|TAG}} (& update the other one nearby to do
>>>>> that for consistency). If you like.
>>>> Will do
>>>> 
>>>> ================
>>>> Comment at: test/DebugInfo/X86/inline-seldag-test.ll:14
>>>> @@ -13,3 +13,1 @@
>>>> 
>>>> -; CHECK: [[F:.*]]: DW_TAG_subprogram
>>>> -; CHECK-NOT: DW_TAG
>>>> ----------------
>>>> dblaikie wrote:
>>>>> I see you dropped the abs def checking in this case - why this case &
>>>>> not others?
>>>> Because in this case, noone else tries to match a TAG_subprogram, the test
>>>> bellow is for an inline_subroutine.
>>>> 
>>>> http://reviews.llvm.org/D5466
>>>> 
>>>> 
>>> 
>>> 
>