From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Keith Seitz <keiths@redhat.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] gdb/testsuite: Add gdb_test_multiple_name variable
Date: Wed, 02 Oct 2019 13:03:00 -0000 [thread overview]
Message-ID: <20191002130351.GC4962@embecosm.com> (raw)
In-Reply-To: <83e83e2a-c0f8-5721-ad76-8b842aaad390@redhat.com>
* Keith Seitz <keiths@redhat.com> [2019-10-01 10:41:40 -0700]:
> On 10/1/19 10:28 AM, Andrew Burgess wrote:
> > After this patch you can now write this:
> >
> > gdb_test_multiple "print foo" "test foo" {
> > -re "expected output 1" {
> > pass $gdb_test_multiple_name
> > }
> > -re "expected output 2" {
> > fail $gdb_test_multiple_name
> > }
> > }
>
> OMG, why didn't *I* think of that!?!
>
> > The $gdb_test_multiple_name is setup by gdb_test_multiple, and cleaned
> > up once the test has completed. Nested calls to gdb_test_multiple are
> > supported, though $gdb_test_multiple_name will only ever contain the
> > inner most test message (which is probably what you want).
>
> Your patch looks good to me (but I am not a maintainer), but I wanted to
> ask if you considered using a stack to more robustly solve the nesting
> problem? It might be unnecessary today -- even overkill -- but I
> would think it is much easier on the eyes.
Is your suggestion that we maintain a separate global test name stack
and push/pop the latest test name to the stack? This would have the
advantage that a nested action element could access the names of outer
scopes, but this feels to me like something that would be both a
pretty rare requirement, and something that can easily be solved by
the user setting up some global variables as needed.
On the question of robustness, I'd be interested to know if you've
spotted a possible bug. My intention is that the TCL program stack
should serve to backup any existing value of gdb_test_multiple_name,
so there should never be a case where we have the wrong test name in
place.
Thanks,
Andrew
>
> We have such support in the test suite already. See
> testsuite/lib/data-structures.exp. [I am not suggesting any
> changes, just trying to raise awareness for ::Stack et al usage
> in the test suite.]
>
> Keith
next prev parent reply other threads:[~2019-10-02 13:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-01 17:29 Andrew Burgess
2019-10-01 17:41 ` Keith Seitz
2019-10-02 13:03 ` Andrew Burgess [this message]
2019-10-02 17:17 ` Keith Seitz
2019-10-03 10:02 ` Andrew Burgess
2019-10-01 18:31 ` Pedro Alves
2019-10-06 8:24 ` Tom de Vries
2019-10-07 10:28 ` Andrew Burgess
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=20191002130351.GC4962@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
/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