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 2B25C383378D for ; Wed, 22 Jun 2022 16:07:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B25C383378D Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-290-JuBktucwMlSn3zRVpp6Zsw-1; Wed, 22 Jun 2022 12:07:31 -0400 X-MC-Unique: JuBktucwMlSn3zRVpp6Zsw-1 Received: by mail-wr1-f71.google.com with SMTP id m7-20020adfa3c7000000b0021b94088ba2so2091099wrb.9 for ; Wed, 22 Jun 2022 09:07:31 -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:in-reply-to :references:mime-version:content-transfer-encoding; bh=6x/6IOuQYDWa6jZpbyV45xAfdy7+9shgkroeLAm1L0M=; b=R/UDXFy69dVMfexAsYg9R5Wlu5VsjvQLzS82slsd3B2WGXcEs0l4Zrr4rcVGKcZHEl zuyOwtwIRn1AEdrlLx8fVrgEJMsH8OBrON+vJ9FqiRwk3O4mPMaplQUL3N+w2HyUcDNa TV0et2Qr4W9+K5zY1+ftaYBEJFSDeYQF7yEaO1gDpWUXHusfu2WzDW5NwUoe4ChOj1K5 7s7yseHwLq2LUHlUwWB/YOrI6acsoktOCUBwbO7p1mpO3k33H3M0kRnF3kvN0uI9RjBj Z3NI+3wvS+6y/KU9OufwD8ADVi42EobKnbO44nm4TkLTwGCAB8zcm4EHQ4KGRWIAF+7f +qdA== X-Gm-Message-State: AJIora/agQkn0GwNbrspCUIUnoQeIacHAoyamNqWSRTGVgrTayUHFzC3 RVMKVFEEQmhz4oNoISGDnxHlzLifoE6ykvr3RBWB+pwIKQHGWG4xPaSnIzGBzScx5MRSAlMsqN7 SNFyZal/MgMCFq/FxlPDe6dhRayEcPZ8rHZDjKPvF8CvJ6+mrR59vzJg9GSV6+ZGolCPef041pA == X-Received: by 2002:a7b:c927:0:b0:3a0:2d6b:9e92 with SMTP id h7-20020a7bc927000000b003a02d6b9e92mr1264293wml.144.1655914049996; Wed, 22 Jun 2022 09:07:29 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vOcP+XKYRrvExSm1EqNC30S+i3gJml6qHI58gXbUta5zWgQ8ttbmXBJMm/Paf9HfsnmJCMGA== X-Received: by 2002:a7b:c927:0:b0:3a0:2d6b:9e92 with SMTP id h7-20020a7bc927000000b003a02d6b9e92mr1264260wml.144.1655914049628; Wed, 22 Jun 2022 09:07:29 -0700 (PDT) Received: from localhost ([195.213.152.79]) by smtp.gmail.com with ESMTPSA id n17-20020a5d4c51000000b0021b962f4256sm5950470wrt.80.2022.06.22.09.07.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jun 2022 09:07:29 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv2] gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc Date: Wed, 22 Jun 2022 17:07:26 +0100 Message-Id: <20220622160726.411122-1-aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <20220622153435.405458-1-aburgess@redhat.com> References: <20220622153435.405458-1-aburgess@redhat.com> 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 16:07:34 -0000 Please ignore patch v1, there was a stupid error. Here's the real patch. 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