public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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

  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).