All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stafford Horne <shorne@gmail.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH v3 1/4] reggroups: Add test and docs for `info reg $reggroup` feature
Date: Sun, 24 Dec 2017 23:47:34 +0900	[thread overview]
Message-ID: <20171224144734.GF32243@lianli.shorne-pla.net> (raw)
In-Reply-To: <00b5d74739aced5252fd0a035397b11f@polymtl.ca>

On Wed, Dec 20, 2017 at 09:58:45PM -0500, Simon Marchi wrote:
> On 2017-12-19 09:22, Stafford Horne wrote:
> > Until now this feature has existed but was not documented.  Adding docs
> > and tests.
> > 

...

> > +proc fetch_reggroups {test} {
> > +    global gdb_prompt
> > +    global expect_out
> > +
> > +    set reggroups {}
> > +    gdb_test_multiple "maint print reggroups" "get reggroups" {
> > +	-re "maint print reggroups\r\n" {
> > +	    exp_continue
> > +	}
> > +	-re "^ Group\[ \t\]+Type\[ \t\]+\r\n" {
> > +	    exp_continue
> > +	}
> > +	-re "^ (\[0-9a-zA-Z\-\]+)\[ \t\]+(user|internal)\[ \t\]+\r\n" {
> > +	    lappend reggroups $expect_out(1,string)
> > +	    exp_continue
> > +	}
> > +	-re ".*$gdb_prompt $" {
> 
> The .* should not be necessary here.

OK.

> > +	    if { [llength $reggroups] != 0 } {
> > +		pass $test
> > +	    } else {
> > +		fail "$test - didn't fetch any reggroups"
> > +	    }
> > +	}
> > +    }
> > +
> > +    return $reggroups
> > +}
> > +
> > +set reggroups [fetch_reggroups "fetch reggroups"]
> > +
> > +foreach reggroup $reggroups {
> > +    gdb_test "info reg $reggroup" ".*" "info reg $reggroup"
> > +}
> 
> This doesn't really test anything.  If you change the line to
> 
>   gdb_test "info reg hello$reggroup" ".*" "info reg $reggroup"
> 
> to fake that the command doesn't work, the test still passes.  So if
> something breaks the feature of "info registers" handling reg groups, the
> test won't catch it.  But I understand the problem, the output is not really
> predictable.  I thought about matching at least one $hex number, but it's
> not even guaranteed (some groups like mmx output nothing).
> 
> What we could do (I'm open to better suggestions) is at least validate that
> it doesn't output "Invalid register", which is the message given when
> passing a register that doesn't exist.  But then, if that message changes
> one day for some reason, the test will become moot again (because GDB will
> output something else than "Invalid register" if the functionality breaks,
> but the test won't catch it).  So in addition, we could also validate that
> "info registers a_non_existent_register" does output "Invalid register".
> This way, if some GDB developers of the future change the message, the test
> will fail, they will go look at your test file, read the comment that you
> will have left, and update the test accordingly.

Right, I will do this.   I will also try to match at least one $hex number
accross all reggroups.  Some will be blank, but if all are blank its probably an
issue.

-Stafford


  reply	other threads:[~2017-12-24 14:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-19 14:22 [OpenRISC] [PATCH v3 0/4] Support for arbitrary reggroups Stafford Horne
2017-12-19 14:22 ` [OpenRISC] [PATCH v3 1/4] reggroups: Add test and docs for `info reg $reggroup` feature Stafford Horne
2017-12-19 16:23   ` Eli Zaretskii
2017-12-20 10:40     ` Stafford Horne
2017-12-21  2:40     ` Simon Marchi
2017-12-21  3:40       ` Eli Zaretskii
2017-12-21  2:58   ` Simon Marchi
2017-12-24 14:47     ` Stafford Horne [this message]
2017-12-19 14:22 ` [OpenRISC] [PATCH v3 2/4] reggroups: Convert reggroups from post_init to pre_init Stafford Horne
2017-12-21  3:03   ` Simon Marchi
2017-12-19 14:22 ` [OpenRISC] [PATCH v3 3/4] reggroups: Create reggroup_gdbarch_new for dynamic reggroups Stafford Horne
2017-12-21  3:15   ` Simon Marchi
2017-12-19 14:22 ` [OpenRISC] [PATCH v3 4/4] tdesc: handle arbitrary strings in tdesc_register_in_reggroup_p Stafford Horne
2017-12-19 16:27   ` Eli Zaretskii
2017-12-19 22:13     ` Stafford Horne
2017-12-20 13:34       ` Stafford Horne
2017-12-20 15:53       ` Eli Zaretskii
2017-12-21  3:29   ` Simon Marchi
2017-12-21 12:55     ` Stafford Horne

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=20171224144734.GF32243@lianli.shorne-pla.net \
    --to=shorne@gmail.com \
    --cc=openrisc@lists.librecores.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.