[PATCH 2/2] Introduce Python testcases to check DWARF output

[Pierre-Marie de Rodat]

On 07/27/2017 10:36 AM, Richard Biener wrote:
> Given that gdb can decode dwarf and we rely on gdb for guality and
> gdb has python scripting can we somehow walk its dwarf tree from
> within a python script?  That is, not need the dwarf decoding or
> objdump requirement?

I’m quite familiar with GDB’s Python scripting API and unfortunately, 
no, it does not provide any access to raw debugging information: 
<https://sourceware.org/gdb/onlinedocs/gdb/Python-API.html>. All we have 
is access to ~source-level entities such as variables, functions and 
types (and “objfiles” themselves, but we can’t do anything interesting 
with them), so there is no way other way than testing dynamic behavior, 
i.e. checking that variables are properly read/decoded, etc. which is 
what we already do in guality tests.

> On IRC I suggested to use pre-existing python DWARF decoders
> which we might be able to import into the tree.  We'd still need them
> to handle non-ELF object formats or somehow extract DWARF from
> other containers to an ELF file (objcopy to the rescue...).
> 
> That said, not needing to write a DWARF / object file decoder
> would be nice.

Yes. On IRC, I mentionned pyelftools 
(https://github.com/eliben/pyelftools/), which knows about ELF and 
DWARF, and that, I think, we could plug on some PE/XCOFF/… extractor to 
parse embedded DWARF. In any case, I feel it would not be simpler than 
what I sent. Of course I’m still open to suggestions. :-)

> I see your testcases have associated .py files.  There are a few
> existing "simple" dwarf testcases that would benefit from being
> able to embed matching into the testcase source file itself?  Thus
> have TCL autogenerate a .py file for the testing from, say
> 
> /* { dg-final { scan-dwarf { "Matcher('DW_TAG_member', 'i',
>                        attrs={'DW_AT_type': Capture('s0_i_type')})" } } } */
> 
> do you think that's feasible or doesn't it make much sense because
> it would essentially match anywhere?  Or we'd end up with a
> gazillion of scan-dwarf variants?

I think this is a good idea! If it is technically possible to have such 
multi-line statements in comments, I think this would be easy. I’ll 
prepare the engine for the next patchset version and I’ll try to find 
existing tests that could be re-written this way. As long as the pattern 
isn’t too generic, I think it would makes sense: for instance if the 
input source has only one structure field called “i”, then the above 
pattern will make it possible to match its type precisely.

> I think a separate .py for checking is required anyway for the more
> complex cases.
I think so as well, for instance for the tests I sent so far.

-- 
Pierre-Marie de Rodat