From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ow72JpN5u2pNkBYAWB0awg (envelope-from ) for ; Tue, 29 Sep 2026 04:40:51 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AecMNe4l; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 87E8B1E033; Tue, 29 Sep 2026 04:40:51 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 9B8DD1E033 for ; Tue, 29 Sep 2026 04:40:50 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AAE564BB24C0 for ; Tue, 29 Sep 2026 08:40:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AAE564BB24C0 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AecMNe4l Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id CD12D4BB24DD for ; Tue, 29 Sep 2026 08:40:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD12D4BB24DD Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CD12D4BB24DD Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790671222; cv=none; b=p49uGBdH02PbLlwaE7nM8V49Ao6vgmZORoAxADbkvN9+5QPlnJF95BslyplmR6NGa0+7DxF9GjBCNrVsVAclDBsKBiTQWT2zcSL6Jc4Qd05DkfuCPeHWSZAFeRtidMplZlLhFhd/onb6UL5ofptb/tkOTTvILeD1uvdbV1kRHOU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790671222; c=relaxed/simple; bh=JoFmrFnjBVMBBSmjFMYeReopeUwTx/WiRz/EkY+4LmI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=dnkoqH0Cd9sPguT9CCPOcPwgIJX60qiB+4iacpacmWVcskCHbx5nsS7DLS/IHX7VN4/m4EMQ/LkAXfXOvwd4vhTpPMPY9wwhNPPcIswHxgL1hBmNLCR6k53PXVIRmqNiDf8PnNCSOhd/M8mk5d8Yyq+KJ5lYO5eS/zf6B2VXXDk= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=AecMNe4l DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD12D4BB24DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1790671220; 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=4Ug2WhbO1DiMLPN39Gt1u5yJoT/3QeuZ3i6z4cYM2qA=; b=AecMNe4lH8qR5HSakXPXrV83zNHVE/Nkpk6ScRJQXGkCGlmHjZuko13fhkRDvGo+JemGBc hmhx+tfA7d5MqEyYze/U5A7gX1s12r2F6YpNli7uEO/Cl4X1pmm+snoyJROYcPiRhWCXBg qoRsl3plLiFa8L8241iEQnLt5D32FKU= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-615-QIB61RtdP0S26fRjoeIDiw-1; Tue, 29 Sep 2026 04:40:19 -0400 X-MC-Unique: QIB61RtdP0S26fRjoeIDiw-1 X-Mimecast-MFC-AGG-ID: QIB61RtdP0S26fRjoeIDiw_1790671218 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-487041c4c82so1233321f8f.2 for ; Tue, 29 Sep 2026 01:40:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790671218; x=1791276018; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4Ug2WhbO1DiMLPN39Gt1u5yJoT/3QeuZ3i6z4cYM2qA=; b=ArXa6NbPoTiL9xphO124jsIu4cyquv34wV3Pb9Fehc4g0SuPdhd1fbZNYr943xIyOW fKI08uEXnyGlAT4JbCuZ/S3uBXsqmC4HVFAVE/MFpNcqHxNg06oO4s2zEhykDIJoU5UZ TAQw96PwpCLvQOsoZhe/j6go+bJKYtx2LNcMLUErWOqJbtVRJcIoIaRTKNi3QNOSaRRe ZVzq98DWZGBQNSS6hiRDvl7zNSdAoGAcM2hRyseqRmvd9pr9krv/JvEQfMK0W1uHiHxv JBpBG1X55hEQEIOCajmXuvMCJhkwAFUZtegEi0jKCh/iDiEMzUAwAM3ihSn7PgkZdQ7M 9hxg== X-Forwarded-Encrypted: i=1; AKwUvBwYrwN1+Ud7+RLXCxVhXTTXFbdcngdnRjhF0RZM4Ciwfb430wOoX9XhLCAsnbq4XuXgfhTAqxwN/eKPaQ==@sourceware.org X-Gm-Message-State: AFq9FYLWF1zZ6Bwmykjb6bojzYOq13CytYWDNF7bXiUNMyWpN9/stwf3 MUllXcclt22WYap6A3APPm49Z70yFMe92kHyqcarSlWC7F4DbM8attS+4uuPoiaWPyVrU9AIppy F2aIdmLKvEPkM4HogevuhFwkzwytUfD6873PxXNNektPh8DPFq3OFWoqF2VERkhhWbUSdXnY= X-Gm-Gg: AYBFou12CyOcOMsvM0O9s0oKpWnv9fATp/JEMKtj84QOZXmhXNNioUOmHqqpWpUhcD5 HlCvle/GRUNn/4Ce5oXLS6fh+8hXQMvqStGDwcqlUfZH6gNRHw2pUw6U9h8h2HmYZLKupc+TJ1h 01AOmzBn43v837MHiD/h0t4OctHCXWQuq0z0F9kVBUNdAjSgrtrsxnlcahcptsVf9+s5Z4p5mtG RbdB4rYZua5G830cMQbigPinKNg7bBF4poJOXxlkeoIS7AOmFEXvIlJQpec/uyA/hVBVeaJ+HUT 6NdEjecvEUTbGnAAjc5DaLb+Sv10PExYy8sVtSNmyCQ9tSgB8u+vYU8XCLR3/o56R8xj X-Received: by 2002:a05:6000:4707:b0:488:6bcb:ec92 with SMTP id ffacd0b85a97d-48872a71ba2mr25614347f8f.17.1790671218057; Tue, 29 Sep 2026 01:40:18 -0700 (PDT) X-Received: by 2002:a05:6000:4707:b0:488:6bcb:ec92 with SMTP id ffacd0b85a97d-48872a71ba2mr25614300f8f.17.1790671217592; Tue, 29 Sep 2026 01:40:17 -0700 (PDT) Received: from localhost ([213.31.44.29]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48af4e8a332sm2650332f8f.0.2026.09.29.01.40.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Sep 2026 01:40:17 -0700 (PDT) From: Andrew Burgess To: Tom de Vries , gdb-patches@sourceware.org Subject: Re: [PATCH v2 2/2] [gdb/testsuite] Use try instead of catch In-Reply-To: <20260927054254.1986148-3-tdevries@suse.de> References: <20260927054254.1986148-1-tdevries@suse.de> <20260927054254.1986148-3-tdevries@suse.de> Date: Tue, 29 Sep 2026 09:40:15 +0100 Message-ID: <8733us1mds.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: hc6dggwCAXHJCYM2SpFz9Tu8eRFs9NCfXDMRIj4ox4g_1790671218 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Tom de Vries writes: > Use try instead of catch in a few places in lib/gdb.exp. That commit message puts a lot of effort onto the reviewers. You really should be explaining the motivation for this patch a little more. Why is this a change worth making? > --- > gdb/testsuite/lib/gdb.exp | 243 +++++++++++++++++++++++--------------- > 1 file changed, 147 insertions(+), 96 deletions(-) > > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index 2cfdbdda09d..e1b59b7a69b 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -2719,7 +2720,10 @@ proc spawn_capture_tty_name { args } { > # if it doesn't work, we want to be notified of that fact via the > # normal Tcl error reporting mechanisms.) The comment above here needs updating. It specifically says: "catch" is used here because .... And is now out of date. > if {[tcl_version_at_least 9 0 0]} { > - catch {fconfigure $spawn_id -encoding utf-8 -profile replace} > + try { > + fconfigure $spawn_id -encoding utf-8 -profile replace > + } on error {} { > + } This doesn't seem like an improvement. Is there some reason why the one line catch is not as good as the try with an empty on error block? > } > return $result > } > @@ -9538,22 +9550,26 @@ proc get_build_id { filename } { > if { ([istarget "*-*-mingw*"] > || [istarget *-*-cygwin*]) } { > set objdump_program [gdb_find_objdump] > - set result [catch {set data [exec $objdump_program -p $filename | grep signature | cut "-d " -f4]} output] > - verbose "result is $result" > - verbose "output is $output" > - if {$result == 1} { > + try { > + set data [exec $objdump_program -p $filename | grep signature | cut "-d " -f4] > + } on error {msg} { > + verbose "result is $msg" It's not really a "result" now, better might be: verbose -log "error is: $msg" this clearly marks it as an error, and also ensures it's always written to the log, not just when running in verbose mode. Though this does make the assumption that this error path is unlikely to occur. If you think that some of these paths will be hit regularly then I would agree with leaving it as just 'verbose "error is: $msg"', no point filling the logs unnecessarily. I think this pattern, calling an 'error' a 'result' occurs a few times. > return "" > } > + verbose "output is $data" > return $data > } else { > set tmp [standard_output_file "${filename}-tmp"] > set objcopy_program [gdb_find_objcopy] > - set result [catch {exec $objcopy_program -j .note.gnu.build-id -O binary $filename $tmp} output] > - verbose "result is $result" > - verbose "output is $output" > - if {$result == 1} { > + try { > + set output \ > + [exec $objcopy_program -j .note.gnu.build-id -O binary $filename $tmp] > + } on error {msg} { > + verbose "result is $msg" > return "" > } > + verbose "output is $output" > + > set fi [open $tmp] > fconfigure $fi -translation binary > # Skip the NOTE header. > @@ -11004,12 +11041,11 @@ proc cmp_file_string { file str msg } { > return > } > > - set caught_error [catch { > + try { > set fp [open "$file" r] > set file_contents [read $fp] > close $fp > - } error_message] > - if {$caught_error} { > + } on error {error_message} { > error "$error_message" > fail "$msg" > return This is a pre-existing bug, but given you're touching this area, could you remove the fail and return please, these are dead code. In fact, isn't this the same as the cleanup in gdb_get_line_number, where we catch an error only to immediately rethrow it? Couldn't we just drop the both catch and not add the try here? Thanks, Andrew