From: Jonathan Wakely <jwakely@redhat.com>
To: Christophe Lyon <christophe.lyon@linaro.org>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, tom@tromey.com
Subject: Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output
Date: Wed, 24 Jan 2024 11:01:45 +0000 [thread overview]
Message-ID: <CACb0b4=uFuHVV_f560vSUjNDspsE44XQPtzSFEW_=wt-WzgXNA@mail.gmail.com> (raw)
In-Reply-To: <20240124104750.1024129-1-christophe.lyon@linaro.org>
On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
>
> GDB emits end of lines as \r\n, we currently match the reverse \n\r,
We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> possibly leading to mismatches under racy conditions.
What do we incorrectly match? Is the problem that a \r\n sequence
might be incompletely printed, due to buffering, and so the regex only
sees (and matches) the \r which then leaves an unwanted \n in the
stream, which then interferes with the next match? I don't understand
why that problem wouldn't just result in a failed match with your new
regex though.
>
> I noticed this while running the GCC testsuite using the equivalent of
> GDB's READ1 feature [1] which helps detecting bufferization issues.
>
> Adjusting the first regexp to match the right order implied fixing the
> second one, to skip the empty lines.
At the very least, this part of the description is misleading. The
existing regex matches "the right order" already. The change is to
match *exactly* \r\n instead of any mix of CR and LF characters.
That's not about matching "the right order", it's being more precise
in what we match.
But I'm still confused about what the failure scenario is and how the
change fixes it.
>
> Tested on aarch64-linux-gnu.
>
> [1] https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
>
> 2024-01-24 Christophe Lyon <christophe.lyon@linaro.org>
>
> libstdc++-v3/
> * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> ---
> libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp b/libstdc++-v3/testsuite/lib/gdb-test.exp
> index 31206f2fc32..0de8d9ee153 100644
> --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
>
> set test_counter 0
> remote_expect target [timeout_value] {
> - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> + -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> send_log "got: $expect_out(buffer)"
>
> incr test_counter
> @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
> return
> }
>
> - -re {^[^$][^\n\r]*[\n\r]+} {
> + -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> send_log "skipping: $expect_out(buffer)"
> exp_continue
> }
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-01-24 11:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 10:47 Christophe Lyon
2024-01-24 11:01 ` Jonathan Wakely [this message]
2024-01-25 15:54 ` Christophe Lyon
2024-02-06 9:26 ` Christophe Lyon
2024-04-10 13:43 ` Christophe Lyon
2024-04-11 11:01 ` Jonathan Wakely
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='CACb0b4=uFuHVV_f560vSUjNDspsE44XQPtzSFEW_=wt-WzgXNA@mail.gmail.com' \
--to=jwakely@redhat.com \
--cc=christophe.lyon@linaro.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
--cc=tom@tromey.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).