From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2205) id 0241738582BD; Fri, 11 Nov 2022 14:30:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0241738582BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668177048; bh=Zd8KBm1r8u+UDsdqDXURL/EjA/DZQjWpkOoMQAHbGyk=; h=From:To:Subject:Date:From; b=C6VAfTbAWW53rhmboIGio29ryVJ12doohytWhIL2sVGu93QVqvflgx3kmoKxFdkzy Bc7ueN1ILy+P3x2UdAwz9piRr4m6dzToGzO6ropYM8wHYHNAbGgio420fJGQ4Ni+jl JbVAulfA5miW6tpzNh3SrGqf38nee+9etA6Ii2rA= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Tom de Vries To: gdb-cvs@sourceware.org Subject: [binutils-gdb] [gdb/testsuite] Better error checking in has_hw_wp_support X-Act-Checkin: binutils-gdb X-Git-Author: Tom de Vries X-Git-Refname: refs/heads/master X-Git-Oldrev: 40b355f24ec288c29bc9d3dd569758b5e80b51e3 X-Git-Newrev: 4f04dba96d4783bae62e7fe4a5eace9fc414723d Message-Id: <20221111143048.0241738582BD@sourceware.org> Date: Fri, 11 Nov 2022 14:30:47 +0000 (GMT) List-Id: https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D4f04dba96d47= 83bae62e7fe4a5eace9fc414723d commit 4f04dba96d4783bae62e7fe4a5eace9fc414723d Author: Tom de Vries Date: Fri Nov 11 15:30:44 2022 +0100 [gdb/testsuite] Better error checking in has_hw_wp_support =20 With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_su= pport usage, which was already fixed on trunk by commits: - 13f72372413 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc= "), and - 01a32ee0b8c ("PowerPC, fix gdb.base/watchpoint.exp on Power 9") =20 While looking into these ERRORs and the commits that fix them, it occur= red to me that while the commits fix the root cause, the failure mode is not g= reat. =20 The test-cases expect a running instance of gdb upon return, which is n= ot there, so there's an long stream of ERRORs generated as a result. =20 Fix this at the start of has_hw_wp_support, by (instead of accomodating= a running gdb instance by calling gdb_exit), checking whether it's called without a running gdb instance, and erroring out otherwise. This way, = there's just one error. =20 I also noticed that in case we do an early exit due to !runto_main, we = don't clean up, so copy the missing cleanups (gdb_exit and $obj file deletion= ) from the regular exit. =20 Tested on x86_64-linux, using has_hw_wp_support for x86_64 in skip_hw_watchpoint_tests. Diff: --- gdb/testsuite/lib/gdb.exp | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 3e0a46445ca..d70b6410441 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -9045,9 +9045,15 @@ gdb_caching_proc has_hw_wp_support { # support for HW watchpoints. global srcdir subdir gdb_prompt inferior_exited_re =20 - set compile_flags {debug nowarnings quiet} set me "has_hw_wp_support" =20 + global gdb_spawn_id + if { [info exists gdb_spawn_id] } { + error "$me called with running gdb instance" + } + + set compile_flags {debug nowarnings quiet} + # Compile a test program to test if HW watchpoints are supported set src { int main (void) { @@ -9063,12 +9069,14 @@ gdb_caching_proc has_hw_wp_support { return 0 } =20 - gdb_exit gdb_start gdb_reinitialize_dir $srcdir/$subdir gdb_load "$obj" =20 if ![runto_main] { + gdb_exit + remote_file build delete $obj + set has_hw_wp_support 0 return $has_hw_wp_support }