From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id 1DE493858C56; Thu, 11 Apr 2024 11:01:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1DE493858C56 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1DE493858C56 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712833277; cv=none; b=tAzxWRw8grpPpQiKQ+wULRbKI+Lzj0FBgTxB6PenYJxfxxw3RqGNXUJ3tZ++NW/rSTbmdsyHTGX5+qsDk1TiiJ0Xa4tzdHkd74w+ZIPg1H2zKWR2GO6qwC8Jg1qHxjITL3nzEl07G33eOyAiv+vAxmxWVblBRGSfwfPmT03Nve4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712833277; c=relaxed/simple; bh=Yqp3+vBkMLsDi2I6UPdYVT+R9oaeUzIdLU0ScuWBuxg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=clqqfzSMrxBWahI5DBHX+PC8WYSDklE+t9YF7C5HCadEDfpXUXvZsu5VSw3hEanf83tWliaTqYIuKlXDECUj/lFpHuvkMh7E2G2qu8onhWa8l/j/zkqP6JLaPxra2pzI/lRrtyVlVA7oliOtg2iGwxivSMVb7U8mDQKATCt6uAc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a4715991c32so1021217266b.1; Thu, 11 Apr 2024 04:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712833273; x=1713438073; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WEb3yxWfnQeJb7ztJbiIVVboQ3MK51z71uQiSdYjnbU=; b=j9YsXZdalURpp3gfLhIojhSaFUKUIWaj0PU2oTVzRdMShDnETHJVsFK558sm/VNGhV 0XZCzAFxEiUKLZJyEAGt878hRIhTIX8nZur86+1ymHSqnk31fAWn4SFWnt0UHeXNiaZZ GM75PnXiylv5CPV+Lg1AaZhZJwMGVkCXYYDphyyDzSSyalPzF2yOHzQRLe4XYA40sDfR TOo+sFsMQZlQxgaUkB7QGJfQYih2SN/euTQf2im/c+S2CzQTTHM+DdFlpj69jHFihppv 46R16woX7dtjUi+Ag+IbkyUa3jzedhoT335tOhAU++lcNgTTn2fmZfveVUP9PjjqlYY2 j4+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712833273; x=1713438073; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WEb3yxWfnQeJb7ztJbiIVVboQ3MK51z71uQiSdYjnbU=; b=pToNfmk9sUw/CzpHTZ/HbAImBDiGIhS1mxYJOn26JOa8pg1rAMiHOvNWhbIgpmtgt0 TzIwKqMWmrx3U3GGN49G8uHtdM1XUlVTZvUrUlvRK4X2m6GrOT6xRdP34o5N09rRKUr5 AQw8w0yF3TnOahrAv/Rzx9CApyZQzkARryPQK0B6eoXz82LVLyO6TFz4gmDj5BL3wewi iInGAhbVrY/u5TSyJrdWH5ECPcAIoDqJenwTMmDGeYfjlJdKlaIFiOYyguAvBJUDoRb9 HrhYvJgYBR2NQowoykpkwGhOXf9EFytVCSN7ovb7gtUDtnZi0NhfrKhK9Qgu6iQsnt/V fWag== X-Forwarded-Encrypted: i=1; AJvYcCUv0k6MK1dgajLR9TkrNw505FdKS31KNlU1C7WR8b7N7qT1l0oZChRc7ypuW+zBafo3v+EzsTtcLw3oLdTr6uvzsfVydgCkN/CTClZQ3RxpJ8NpQBjhAoOH8gCcuSpF X-Gm-Message-State: AOJu0YyT7Ttcry8EAnCgCrM8Q5QppJps2cKZkWaUyrbUlEDtt4F/yu6F G//F2n0JPbCwEOotgXdDyFOIg8DaMaU0dNbLo4K3ggcUBrgHQgqeREb/9qdYdYazz7NYSQDqAJ1 Ty5eo4vWkKav6eh+ex45vWpFZOIw= X-Google-Smtp-Source: AGHT+IGIEoVvG4gl2laXE83eOpKKxtb/v3CW4dzqnL+TNjgCzppz3OqXNOZbd8btRADvtHHHKujx/jGFvfnriofxNpI= X-Received: by 2002:a17:907:11dc:b0:a4e:d43:dc4b with SMTP id va28-20020a17090711dc00b00a4e0d43dc4bmr3319537ejb.58.1712833272426; Thu, 11 Apr 2024 04:01:12 -0700 (PDT) MIME-Version: 1.0 References: <20240124104750.1024129-1-christophe.lyon@linaro.org> In-Reply-To: From: Jonathan Wakely Date: Thu, 11 Apr 2024 12:01:01 +0100 Message-ID: Subject: Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output To: Christophe Lyon Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, tom@tromey.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 25 Jan 2024 at 15:54, Christophe Lyon wrote: > > On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote: > > > > 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 > > > > Hmm, right, sorry I had this patch in my tree for quite some time, but > wrote the description just now, so I read a bit too quickly. > > > > > > 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. > > > Exactly: READ1 forces read() to return 1 byte at a time, so we leave > an unwanted \r in front of a string that should otherwise match the > "got" case. > > > > > > > > > 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. > > > > I followed what the GDB testsuite does (it matches \r\n at the end of > many regexps), but in fact it seems it's not needed: > it works if I update the "got" regexp like this (ie. accept any number > of leading \r or \n): > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} { > + -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} { > and leave the "skipping" regexp as it is currently. > > Is the new attached version OK? Yeah this makes more sense to me now, thanks. OK for trunk. > > Thanks, > > Christophe > > > > > > > Tested on aarch64-linux-gnu. > > > > > > [1] https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269 > > > > > > 2024-01-24 Christophe Lyon > > > > > > 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 > > > > >