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.133.124]) by sourceware.org (Postfix) with ESMTPS id CF4CD3841455 for ; Mon, 27 Jun 2022 13:41:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CF4CD3841455 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-530-DWY3nhGLMFWmWBfixXWvqQ-1; Mon, 27 Jun 2022 09:41:42 -0400 X-MC-Unique: DWY3nhGLMFWmWBfixXWvqQ-1 Received: by mail-wr1-f70.google.com with SMTP id g5-20020adff3c5000000b0021bc44c0f7aso587667wrp.22 for ; Mon, 27 Jun 2022 06:41:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=+AdoGtMYYcFNonHkAxAfBJzmYOwS/KoctqOURJW00Vk=; b=elgXjsDHXqMi653Dk9LPpKTSKHuekoVcYfkbPgOrIzVtK55ImwuIV1IZveXUNFDK4l QY9EEyFSlcc1jDZgMypDcUhkXCkDO7+qghKjD1TI4+zuBT+q1eAuj6kAvIY/f+vTIBt7 uzps39Ibhg26fseO7uVUgELzImcS40Mb6KXjYeVa+g3A5QGlgEAdW355zkwVuAWJBJg/ KwNsXxJ/78q5Z+wI+fh1V4leXNX6SNbggasDVAAO00oFXmWhAKomqaXYPqeYorrwRrsq HLSQnoDakUe61Lzn06jr5MlPhtNTzTE+t9YRF30yWXllns4ui8ltG8PwCX47/6R6tmar 7p6Q== X-Gm-Message-State: AJIora8UQMD12Hb3zLpqZgc2mXHlohOJRUMxdRzG9MST7tAegdNnvknb WLi2xXuOQI4taABdIpTsQHtoS0pfXaT+ki9c3431ddMoSdMordIRPkGsoNnZjPeV4aDpa7QIlub qQA3q6o+qYEb2ATifiv2gYfCJJiF9anlv7OE3k9PurunqZw4PlBmhDPfi4PvbNARWbVufdiZkiQ == X-Received: by 2002:a5d:4251:0:b0:21b:885b:2fcc with SMTP id s17-20020a5d4251000000b0021b885b2fccmr12821177wrr.52.1656337301058; Mon, 27 Jun 2022 06:41:41 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u62RATn0+WyidclxCp3xKqtCRfpypHfy3+vAKZ1cSwORMteVYPP2Rmbawket61XF6YpDG3iw== X-Received: by 2002:a5d:4251:0:b0:21b:885b:2fcc with SMTP id s17-20020a5d4251000000b0021b885b2fccmr12821150wrr.52.1656337300791; Mon, 27 Jun 2022 06:41:40 -0700 (PDT) Received: from localhost (15.72.115.87.dyn.plus.net. [87.115.72.15]) by smtp.gmail.com with ESMTPSA id ay36-20020a05600c1e2400b0039746638d6esm13400884wmb.33.2022.06.27.06.41.40 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jun 2022 06:41:40 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Subject: Re: [PATCHv2] gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc In-Reply-To: <20220622160726.411122-1-aburgess@redhat.com> References: <20220622153435.405458-1-aburgess@redhat.com> <20220622160726.411122-1-aburgess@redhat.com> Date: Mon, 27 Jun 2022 14:41:39 +0100 Message-ID: <87ilomdy0c.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=-10.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 13:41:45 -0000 Andrew Burgess writes: > Please ignore patch v1, there was a stupid error. > > Here's the real patch. Carl already posted a patch for this issue, which is being discussed here: https://sourceware.org/pipermail/gdb-patches/2022-June/190094.html Thanks, Andrew > > Thanks, > Andrew > > --- > > When running the gdb.base/break-idempotent.exp test on ppc, I was > seeing some test failures (or rather errors), that looked like this: > > (gdb) watch local > Hardware watchpoint 2: local > > has_hw_wp_support: Hardware watchpoint detected > ERROR: no fileid for gcc2-power8 > ERROR: Couldn't send delete breakpoints to GDB. > ERROR OCCURED: can't read "gdb_spawn_id": no such variable > while executing > "expect { > -i 1000 -timeout 100 > -re ".*A problem internal to GDB has been detected" { > fail "$message (GDB internal error)" > gdb_internal_erro..." > ("uplevel" body line 1) > invoked from within > > What happens is that in break-idempotent.exp we basically do this: > > if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} { > continue > } > > # .... > > if {![skip_hw_watchpoint_tests]} { > test_break $always_inserted "watch" > } > > The problem with this is that skip_hw_watchpoint_tests, includes this: > > if { [istarget "i?86-*-*"] > || [istarget "x86_64-*-*"] > || [istarget "ia64-*-*"] > || [istarget "arm*-*-*"] > || [istarget "aarch64*-*-*"] > || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support]) > || [istarget "s390*-*-*"] } { > return 0 > } > > For powerpc only we call has_hw_wp_support. This is a caching proc > that runs a test within GDB to detect if we have hardware watchpoint > support or not. > > Unfortunately, to run this test we kill the current GDB session (call > gdb_exit), start a new session, and, when the test is completed, we > kill the test session. This leave DejaGNU with no running GDB > session. > > Now has_hw_wp_support is a caching proc, so we only do the kill > session, run test, and cleanup the first time has_hw_wp_support is > called, but, this means that the first time we call > skip_hw_watchpoint_tests in a single DejaGNU run, we carry out these > extra steps. > > Every other use of skip_hw_watchpoint_tests is just at the stop of a > test script, and is used to return early, entirely skipping the script > if hardware watchpoint support is not available. > > Only in break-idempotent.exp and process-dies-while-detaching.exp do > we call skip_hw_watchpoint_tests from the middle of a test script. In > the process-dies-while-detaching.exp case we immediately call > clean_restart anyway, so if the skip_hw_watchpoint_tests call does > close the current GDB session we're fine. > > But in break-idempotent.exp we call skip_hw_watchpoint_tests with GDB > running, and we expect GDB to be running when the call finishes. On > powerpc this might not be the case, and as a result we see the errors > above. > > To fix this I propose adding an extra call to skip_hw_watchpoint_tests > to the top of break-idempotent.exp, this call will prime the cache > with the result of the check. Now, when we later make a call to > skip_hw_watchpoint_tests, instead of running the test we will simply > reuse the cached result. > > After this change break-idempotent.exp runs fine on powerpc. > --- > gdb/testsuite/gdb.base/break-idempotent.exp | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/gdb/testsuite/gdb.base/break-idempotent.exp b/gdb/testsuite/gdb.base/break-idempotent.exp > index 29002f103a8..a51b59e251e 100644 > --- a/gdb/testsuite/gdb.base/break-idempotent.exp > +++ b/gdb/testsuite/gdb.base/break-idempotent.exp > @@ -36,6 +36,23 @@ > > standard_testfile > > +# For some architectures (just powerpc right now), this test will > +# invoke a caching proc that closes the current GDB session, and > +# starts a new session in which to run the test. Once the test is > +# complete, GDB is exited, leaving no GDB running. > +# > +# Later in this test script we will call this function (directly, and > +# indirectly) multiple times, after starting GDB, and we expect GDB to > +# still be running after this test is complete. As a result of the > +# above, the first time this test is run, we will break this > +# assumption, and GDB will not be running when we expect it to be. > +# > +# Luckily, the test is a caching proc, and so it is only the first > +# call to this function that causes GDB to exit. Any later calls will > +# simply use the cached result. So, we call this function now, before > +# we've started GDB, and this will prime the cache. > +skip_hw_watchpoint_tests > + > # Force a breakpoint re-set in GDB. Currently this is done by > # reloading symbols with the "file" command. > > -- > 2.25.4