[PATCH] [dwarfdump] Print the name for referenced specification of abstract_origin DIEs.
Eric Christopher
echristo at gmail.com
Fri Oct 3 17:00:16 PDT 2014
On Fri, 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.
>
> 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.
This I would be particularly down for. :)
-eric
>
> -- 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
>>>>
>>>>
>>>
>>>
>
More information about the llvm-commits
mailing list