From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id D88EB3858C39 for ; Wed, 10 Apr 2024 13:43:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D88EB3858C39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D88EB3858C39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::531 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712756600; cv=none; b=jw1Nau+xPZUPEQ9q1/s6Yh1BO4yYIF05XO3IAYIN7ZUDzKeH7uYITICJeUFxBi2684cMBGLpWX3eXP/FUAM2vZU81uocvfPktzO8HFt5ueOLOdseMUedNEmoTAZ7YzQIczVFde+iTXB/i193SM0WKLYlmEzJQWaro5+sj8A2sMI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712756600; c=relaxed/simple; bh=81ExqMrtM7FCAtHTPCzYcZlPhYMo8f7G3meE9fDF3JQ=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=X/MnlO8JZnjWrVwyoZ96uBCUfaWoz9yYDnFFqA3K9rpTnGss6wMdSw3fLk8S+Yd6LXP/3foQ65xjy9/w9MDiVP0utzJotdJOJMrK88bvco1bKqAGn7wRa+LNw4JBb2IX/HLsA94xGUzwmnqEF7fBBtieA8FjpmxKYv+MO6TG2RA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-56e6282dd72so4154243a12.3 for ; Wed, 10 Apr 2024 06:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712756596; x=1713361396; 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=PQ1t5gUw0sOM8d4SPMe3+cXEULrMht84ToEW8e9r3MU=; b=kLKYj+yPVeuTQ5QZ2BDScbY+MVUzJSitfO51dSYdz7PlyY4V+wmnXT9iK5ezPVweKB Q28fs/Mm4mQSUPJ4vo6lFD0rFdGKNZICo2Fbl1hY0fKQew8KUatv+oXnaLGG62cV2LNQ adMnFXbvVJoFf6JLltm/joEsTJHhGKY+/I8ZrKKAvdQ7xPP5miYMLoCr9VJRPRG+Tj9A 5A7NDVQiHw1fvvmM0heYrToAzQlGLbE2rzcAXZ42VtE0rOKt82a/mYkfDXlLNtj7quNj jjJr4CpWgaapgKxetq/W2uqtg1sFd21Es/pjGJuU1xvWSPAd7AkMQ/YOom8pTJZAIqqw BEQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712756596; x=1713361396; 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=PQ1t5gUw0sOM8d4SPMe3+cXEULrMht84ToEW8e9r3MU=; b=cLR813UnMusZX7tgOAILsPBpSjAtPG92srM3EN76z8OZwYQ0QWeRTUjss646xT3aiG RVz1D9rB268zivXqzkAhEWmRr8Ua8NyzNmgDkHmCWRsLX5yjaErzk0xmit6+Af21oky3 70ZTsoWfjk6BUhiZJFb+AFTMugB214ufDJeld+2PjsnEzKlRoei1gK6e8lvn/WS2v6aj CKoq8kfD87KoxrQvreENYATsJAsuO8tWR0CriqluwDmCm0rmCNGyLVIwH8E8BhXK6KOf uYypbLV/uk7PObFeZudYyqLsTomMuWFSt/dUodCteZCQxkOjy4KKmkND8/driDP7kmo2 NYlw== X-Gm-Message-State: AOJu0YyMohkn5fiY3pF0ZYTXxFV1Kr40u0l8JC1xQ6nufYp847g5KaUk /NFD+KGhVAswvmO6heywJ1uJ8/heNw3fZotu94Xs1U0FEHg2jnOTOpbGbXWZl7laCaxG3V7P2ax Rv6hNgCvzxwJo9KtnmhPgkSEAIbJJLWvbusGGPg== X-Google-Smtp-Source: AGHT+IHMGnmOWUduIo8aLFyA1gx/+Km33humPPPzZmCm9PifLfnExu38A3kecBg8Ft9ifsoOQZWVQoIHz1fBf/GRrCY= X-Received: by 2002:a50:931e:0:b0:56e:215b:75c2 with SMTP id m30-20020a50931e000000b0056e215b75c2mr1654096eda.17.1712756596265; Wed, 10 Apr 2024 06:43:16 -0700 (PDT) MIME-Version: 1.0 References: <20240124104750.1024129-1-christophe.lyon@linaro.org> In-Reply-To: From: Christophe Lyon Date: Wed, 10 Apr 2024 15:43:09 +0200 Message-ID: Subject: Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output To: Jonathan Wakely Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, tom@tromey.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: ping? On Tue, 6 Feb 2024 at 10:26, Christophe Lyon wrote: > > ping? > > On Thu, 25 Jan 2024 at 16: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? > > > > 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 > > > > > > >