From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 72C3C3858D37 for ; Fri, 28 Apr 2023 21:50:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72C3C3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682718632; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=LnwKSgKUZvl6tycWkSIv4NOgYyXWt5g0gth2+PBWuIU=; b=UoX9b0wvK7nsOtsYo5UrXft16tbqfUAYF0kGdVK9Xf+vnuWyxFBebxfOah1+JSFUbnmquZ G9g4BbIQbUrTxoDW76nmlZh/TC8I2OQZZxuNS7m+dVISIuyfyAPaoCd+ylDLY6mpP643hs kEjrA31A13du2ThH5pojhb/uB8sz3VA= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-645-1MKPql-fOQqG9n570keXNg-1; Fri, 28 Apr 2023 17:50:30 -0400 X-MC-Unique: 1MKPql-fOQqG9n570keXNg-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-3f08901fed3so1106945e9.1 for ; Fri, 28 Apr 2023 14:50:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682718629; x=1685310629; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LnwKSgKUZvl6tycWkSIv4NOgYyXWt5g0gth2+PBWuIU=; b=PUlP3blIEVB6coB1iEE+xP6OhrdirmXvdlQbK98i6IiZFxm8iWR946WnmL3xDToYoK 7WVOiWXRtFpII9LSffkiikeM0eC33k9jWPJ2s6r/heUPx3mFIMyjRPhqiJcCsrovLlRi srzX/mQuA4t0XpTr7UY6HX35IY2+O0Hggp7laYu/Cmv8nCfYlvGH1Hl7zE5je0G17zfS Cx2k/TH74kcoqGXXT0H44WH4PMps1K684EEIiWvRsjlOzm0u5gCqD88Jj7XlcYvKc5Bk c0eKWHQDw9xG6aDGz891tHQlNv/r2WwqNZ86MUCVnDMj638u6OMKjZJOtzlQ5YVTo8Po F5BQ== X-Gm-Message-State: AC+VfDzh+obL0NNl9X4ohkBaSGhGUie8DCFnGsa8Fg26ts8Hu5XMWDa6 Q4xYaI2v06Pmzz62nPW3I3xzBuuj9L92+qAhdtOpwtwVfTpDZ+YvUsKlE/EcRpEnSCRVrD48+hb a3bfktk4gQA555xyKtiS5l16o6S/Z9Q== X-Received: by 2002:a1c:f719:0:b0:3f1:71b2:9445 with SMTP id v25-20020a1cf719000000b003f171b29445mr5294790wmh.15.1682718629567; Fri, 28 Apr 2023 14:50:29 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7eLzfyGm/32+R2qhPZN0pFSQtDtRMKSXg1KOo4kG7yhSsx1Z/ech8P/wvan+8YLn0E3xZD1Q== X-Received: by 2002:a1c:f719:0:b0:3f1:71b2:9445 with SMTP id v25-20020a1cf719000000b003f171b29445mr5294781wmh.15.1682718629222; Fri, 28 Apr 2023 14:50:29 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id x8-20020a05600c21c800b003f2390bdd0csm16734688wmj.32.2023.04.28.14.50.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Apr 2023 14:50:28 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH 4/5] gdb/testsuite: change newline patterns used in gdb_test In-Reply-To: <46010910-4b1f-7322-e273-57a09b9f4669@simark.ca> References: <464e64e3a3483c228f0a73c778bcaf79e4595abd.1680293848.git.aburgess@redhat.com> <9c4e4ce6-9986-1c3a-9885-f4f3388e95f6@simark.ca> <87r0s49fa0.fsf@redhat.com> <55449bae-c9ea-4b04-f07e-a4ad2e3d6bf1@simark.ca> <46010910-4b1f-7322-e273-57a09b9f4669@simark.ca> Date: Fri, 28 Apr 2023 22:50:27 +0100 Message-ID: <87leibad7g.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Simon Marchi writes: > On 4/28/23 11:57, Simon Marchi via Gdb-patches wrote: >>> I've pushed the patch below which fixes all the regressions I see when >>> using the native-gdbserver board. >>> >>> I'm still testing with the native-extended-gdbserver board, but I'm a >>> little short of time, so might not be able to fix any regressions that >>> throws up until next week. So I've pushed this fix for now, and will >>> follow up with any additional fixes I find later. >>> >>> Sorry for causing the regressions. >> >> Thanks, I'll let you know if there are more remaining failures. >> >> Simon >> > > I still see these two, which are likely related: > > FAIL: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: stop trace experiment I think we should accept this regression. Here's the gdb.log output: (gdb) PASS: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: run trace experiment tstop Trace is not running. (gdb) FAIL: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: stop trace experiment I changed this test form this: gdb_test "tstop" \ "\[\r\n\]+" \ "stop trace experiment" to this: gdb_test_no_output "tstop" \ "stop trace experiment" The 'Trace is not running.' error is what causes the test to fail. This test has a bunch of other FAILs, one of which is the 'tstart' preceeding the above 'tstop': (gdb) PASS: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: advance to begin tstart locf has been optimized out of existence. locd has been optimized out of existence. Expression pieces exceed word size (gdb) FAIL: gdb.trace/collection.exp: collect register locals collectively: run trace experiment: start trace experiment So clearly, the test script is expecting the tracing to start, but it doesn't. Catching things like the above -- where we were missing a warning/error from GDB was exactly the point of my patch -- so I think this additional failure is acceptable. > FAIL: gdb.trace/pending.exp: ftrace works: stop trace experiment I'm not able to reproduce this one. On my local machine the pending_tracepoint_works proc (in pending.exp) exits early as (according to the comment) the target was unable to install the fast tracepoint. Could you confirm that the 'tstart' test immediately preceding this 'tstop' test passes successfully please, it's name will be: gdb.trace/pending.exp: ftrace works: start trace experiment If this FAILs then I think, like the one above then it's OK that the corresponding tstop also FAILs. If you are seeing the 'tstart' PASS then could you paste in the corresponding gdb.log snippet and I'll see if I can spot the problem. Thanks, Andrew