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 9DE333857424 for ; Wed, 22 Jun 2022 15:34:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9DE333857424 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-124-cc4s3chlOPSZ5F8oDXaMMA-1; Wed, 22 Jun 2022 11:34:41 -0400 X-MC-Unique: cc4s3chlOPSZ5F8oDXaMMA-1 Received: by mail-wm1-f72.google.com with SMTP id p6-20020a05600c358600b0039c873184b9so4261wmq.4 for ; Wed, 22 Jun 2022 08:34:40 -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:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=K0awJFuLOdbniLC22EK+4HvyzRgzLyXJ+m+xTo/imuU=; b=uE6DK1qXegNc/puJBTCKZNm9D1MqpAlE8mMfKecK38kfBYFWHM5EywMv5RDKrfpIys 5wRMpkzqDY2BBc13Kh0ZKFdo5gU+AAf9Os6MLxDex0Je4rnvTgUeNWrrNRghCI7Vljyl UrUCsa5I8sQcF4doBpymPTxc9PjhZXJQ0YA3pEgtqslfliCzAbLI36xisWjDI5R2Ms9q soncQ/MUXL8/Z/CgoguFyunvxVt8sPJRljx0rbZIxQdZBt3HHgRdgquteLtJgrOUOS4l l9UXvsY/rTTSM8Su2VdHVcrePKoBi+N7MDmFUFWAAx6XiHG87Voms2A6hNCIj1YhC+02 XUbg== X-Gm-Message-State: AJIora8W2vXM4GBBssrnKE4u1Bj9q8vxs5EMTKlHFY6+0q1Ha7GMWaqk /sG/ux52P4k/IVLS4xD/vpn/0TLKfGSKvvyev+RGiTMBRholHRxlKCdQqbuY9WFJI2P8rYv8SaJ N7qUx6g07BIfjxLdHdHf3JZg+xtLehZjcP2HQcJHilL8KeiiF0RHCjTGlHWzSzx9j0qdPoIoY4w == X-Received: by 2002:a5d:4352:0:b0:213:4910:6616 with SMTP id u18-20020a5d4352000000b0021349106616mr3951494wrr.226.1655912079533; Wed, 22 Jun 2022 08:34:39 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tgFPz/tTn9pyOf+wmF8FWAUgiIFRzB5CawAVuSINBVIM8tpYGu3kXNXEInPWvMP+6thmODGw== X-Received: by 2002:a5d:4352:0:b0:213:4910:6616 with SMTP id u18-20020a5d4352000000b0021349106616mr3951462wrr.226.1655912079207; Wed, 22 Jun 2022 08:34:39 -0700 (PDT) Received: from localhost ([195.213.152.79]) by smtp.gmail.com with ESMTPSA id q126-20020a1c4384000000b003a02b9c47e4sm2697698wma.27.2022.06.22.08.34.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jun 2022 08:34:38 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCH] gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc Date: Wed, 22 Jun 2022 16:34:35 +0100 Message-Id: <20220622153435.405458-1-aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, 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: Wed, 22 Jun 2022 15:34:46 -0000 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..8866c65e883 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_breakpoint_tests + # Force a breakpoint re-set in GDB. Currently this is done by # reloading symbols with the "file" command. -- 2.25.4