public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pierre-Marie de Rodat <derodat@adacore.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH 0/2] Python testcases to check DWARF output
Date: Wed, 26 Jul 2017 16:01:00 -0000	[thread overview]
Message-ID: <20170726160040.6516-1-derodat@adacore.com> (raw)

Hello,

At the last GNU Cauldron, Richard Biener and I talked about DWARF output
testing. Except for guality tests, which are disabled on several
targets, the only way tests check the DWARF is scanning the annotated
assembly (-dA), making it hard to write reliable tests.

For instance, checking the number of times DW_AT_location is present in
order to check that some specific variable is assigned one is fuzzy.
Depending on the target and on the evolution of the compiler, the number
of output variables, or which one is assigned a location can vary
legitimately but still make the test fail.

On my side, I already had written an out-of-tree testsuite for the DWARF
features I added for Ada. This testsuite uses a DWARF parser in order to
perform checks on a tree:
<https://github.com/pmderodat/dwarf-ada-testsuite/>. I had to update it
a couple of times, for instance when a change created a
DW_TAG_const_type DIE or removed one somewhere in a type tree, but
that’s very rare. I would say that I’m satisfied with the checks I could
express, but I don’t remember I ever caught a regression with them, so I
have no representative experience to share in this area. Maybe DWARF
back-end developpers do a too good job. ;-)

Anyway, Richard and I discussed about doing something similar in-tree,
and here is a candidate set of patches to achieve that:

  * The first patch installs DejaGNU scripts to run a Python interpreter
    in testcases.

  * The second one installs other DejaGNU scripts to detect DWARF
    dumping tools, plus a small Python library to parse and pattern
    match DIEs and their attributes. It also adds several C and Ada
    tests as examples; these are inspired by existing homonym tests
    based on assembly scanning.

For now, this supports only platforms where objdump is available for the
current target, but extending it to other tools, such as otool on Darwin
should be doable.

I would appreciate feedback about the idea and the implementation I
propose. This is the first time I do more in the testsuite than just
adding new tests, so thank you in advance for you patience in reviewing
these. :-)

I tested these patches on x86_64-linux.

             reply	other threads:[~2017-07-26 16:01 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-26 16:01 Pierre-Marie de Rodat [this message]
2017-07-26 16:01 ` [PATCH 1/2] Introduce testsuite support to run Python tests Pierre-Marie de Rodat
2017-07-26 16:25   ` David Malcolm
2017-07-26 16:35     ` Pierre-Marie de Rodat
2017-07-26 16:48       ` David Malcolm
2017-07-27  8:49         ` Pierre-Marie de Rodat
2017-07-27 13:40           ` David Malcolm
2017-08-02 18:43         ` Jeff Law
2017-08-03  8:27           ` Pierre-Marie de Rodat
2017-07-27  8:50   ` Matthias Klose
2017-07-27 10:09     ` Pierre-Marie de Rodat
2017-07-26 16:01 ` [PATCH 2/2] Introduce Python testcases to check DWARF output Pierre-Marie de Rodat
2017-07-26 17:10   ` David Malcolm
2017-07-27  8:59     ` Pierre-Marie de Rodat
2017-07-27  8:36   ` Richard Biener
2017-07-27 10:09     ` Pierre-Marie de Rodat
2017-07-26 16:16 ` [PATCH 0/2] " David Malcolm
2017-07-26 16:26   ` Pierre-Marie de Rodat
2017-07-26 21:25 ` Mike Stump
2017-07-27  7:52   ` Richard Biener
2017-07-27  9:09     ` Pierre-Marie de Rodat
2017-08-03 22:23       ` Mike Stump
2017-08-06 14:35         ` Iain Buclaw
2017-08-02 15:44     ` Jeff Law
2017-08-02 15:43 ` Jeff Law
2017-08-03  8:27   ` Pierre-Marie de Rodat
2017-08-03 16:13     ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170726160040.6516-1-derodat@adacore.com \
    --to=derodat@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).