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
