From: Pedro Alves <palves@redhat.com>
To: "Maciej W. Rozycki" <macro@mips.com>,
Andrew Burgess <andrew.burgess@embecosm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] gdb/testsuite: Handle targets with lots of registers
Date: Fri, 13 Apr 2018 13:10:00 -0000 [thread overview]
Message-ID: <4273f7eb-464a-3abc-fc50-b6598ed3b896@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1804130017080.11756@tp.orcam.me.uk>
On 04/13/2018 12:39 AM, Maciej W. Rozycki wrote:
> On Mon, 9 Apr 2018, Andrew Burgess wrote:
>
>> # Test for a regression where this command would internal-error if the
>> -# program wasn't running.
>> -gdb_test "maint print registers" "Name.*Nr.*Rel.*Offset.*Size.*Type.*"
>> +# program wasn't running. If there's a lot of registers then this
>> +# might overflow expect's buffers, so process the output line at a
>> +# time.
>> +send_gdb "maint print registers\n"
>> +gdb_expect {
>> + -re "^\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[\n\r\]+" {
>> + exp_continue
>> + }
>
> I think this changes the meaning of the test; you want to preserve the
> heading match pattern at the very least. Also `gdb_test' handles various
> error cases gracefully (which matters for the avoidance of excessive
> timeouts with some test boards), whereas your simple matcher does not.
Yeah, there's no good reason to use gdb_expect directly here, AFAICT.
You can do the same thing with gdb_test_multiple, which handles
the timeout already, as well as other error conditions, including
the internal-error the comment the test above mentions.
>
> Also how many is "a lot"? Perhaps you could take the path of least
> resistance instead and simply increase the size of the buffer, like with
> commit ff604a674771 ("gdb/testsuite: Bump up `match_max'"). This could be
> done temporarily for this test only, so as to avoid slowing down `expect'
> throughout the test suite.
I think the exp_continue trick is better for getting rid of the
problem for good. We can still use it, with gdb_test_multiple.
A few comments more:
> + -re "^\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[0-9\]+\[^\n\r\]+\[\n\r\]+" {
Nit: \n\r instead of \r\n kind of reads like a typo to me:
$ grep -rn "\\\\r\\\\n\\\\]" | wc -l
1036
$ grep -rn "\\\\n\\\\r\\\\]" | wc -l
28
I'd suggest flipping it around to the more usual form
just to avoid causing pause when people read the regexp.
> + exp_continue
> + }
> + -re ".*$gdb_prompt $" {
No need for leading .*, it's implied.
> + pass "maint print registers"
> + }
> + timeout {
> + fail "maint print registers (timeout)"
> + }
> +}
> +
So I'd suggest something like this:
set saw_registers 0
set test "maint print registers"
gdb_test_multiple $test $test {
-re "^\[^\r\n\]+\[0-9\]+\[^\r\n\]+\[0-9\]+\[^\r\n\]+\[0-9\]+\[^\r\n\]+\[0-9\]+\[^\r\n\]+\[\r\n\]+" {
set saw_registers 1
exp_continue
}
-re "$gdb_prompt $" {
gdb_assert $saw_registers $test
}
}
The "saw_registers" bit ends up serving as replacement for
seeing the heading, though you can also add a pattern to
match the heading and check it in the gdb_assert instead if
you'd like.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2018-04-13 13:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 15:15 [PATCH 0/3] Small testsuite updates Andrew Burgess
2018-04-09 15:15 ` [PATCH 1/3] gdb/testsuite: Fix broken regexp in gdbstub case Andrew Burgess
2018-04-13 12:12 ` Pedro Alves
2018-05-03 19:41 ` Andrew Burgess
2018-05-04 9:18 ` Pedro Alves
2018-04-09 15:15 ` [PATCH 2/3] gdb/testsuite: Filter out some registers for riscv Andrew Burgess
2018-04-09 21:28 ` Palmer Dabbelt
2018-04-09 22:26 ` Andrew Burgess
2018-04-10 20:25 ` Palmer Dabbelt
2018-04-13 12:55 ` Pedro Alves
2018-04-09 15:15 ` [PATCH 3/3] gdb/testsuite: Handle targets with lots of registers Andrew Burgess
2018-04-12 23:40 ` Maciej W. Rozycki
2018-04-13 13:10 ` Pedro Alves [this message]
2018-04-13 13:57 ` Maciej W. Rozycki
2018-05-04 12:01 ` Andrew Burgess
2018-05-04 12:47 ` Pedro Alves
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=4273f7eb-464a-3abc-fc50-b6598ed3b896@redhat.com \
--to=palves@redhat.com \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@mips.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).