From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id saKSOEitomrRxTwAWB0awg (envelope-from ) for ; Thu, 10 Sep 2026 09:14:48 -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=VCfgDCy4; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E312F1E09E; Thu, 10 Sep 2026 09:14:48 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 3407E1E091 for ; Thu, 10 Sep 2026 09:14:48 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 64BF448F60F1 for ; Thu, 10 Sep 2026 13:14:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64BF448F60F1 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=VCfgDCy4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 1BA324BA900A for ; Thu, 10 Sep 2026 13:14:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1BA324BA900A 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 1BA324BA900A Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789046050; cv=none; b=xuisBzUQQvyKr/RFvdGJ+zZtNDxtmQKtjMooATb4oVr3tXoHz6eJ/yr9AIN8SWfDwvDqojK05cwEamhJolNHmb0QMQHe8GdkY/KLPH5UMeHPm5EJo5NKxluXZubw2ZhhAHPl0oHNIqhObBZBD7a0lbwsZpDZR3BOgQLpTV7r8is= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789046050; c=relaxed/simple; bh=lv2xRIYuFpJ6G0vk255cYCmu92D0w0DNamEY3ywYVrw=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=TBFeyE6v3PL/2bdAEo8SrwxfQ+5NTvr7+Ldjue1miETvAytd4E5w8TxX+jpP3NcG8JLNWvdUNXYuEn3BWo7IpoGEvR7qzcdu9jIApR9X+IUeJxB7Zm/KSti6j3r1c5kOFSkTl9OSgNtErPPJFXyel/9nCTqf3mCMSqJPT/ZfyyA= 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=VCfgDCy4 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1BA324BA900A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789046048; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0RBdCvOXR8GdbPGyu0+w4vAq1GaMHqM0XN6uWGZwgMU=; b=VCfgDCy4i1H3wIYFYCBDkTwIr6oV7d4fti+PNRmqKOqccD2vBdUiE+ijJ+b1naQqYULY4v dc/CoG28a2PBeAo7n7Rme+Rx1yvnxLX1PUD1+/5jhJiTGxTAKoy+xct1WJBTk8ujvz6k9z ciSTfkiiQhP1ETgLO2HqzHqEJyeopJc= 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.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-54-FQ1pKjBcOcuhbvfGUZJ4bw-1; Thu, 10 Sep 2026 09:14:07 -0400 X-MC-Unique: FQ1pKjBcOcuhbvfGUZJ4bw-1 X-Mimecast-MFC-AGG-ID: FQ1pKjBcOcuhbvfGUZJ4bw_1789046046 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4994cf6cdb9so51090665e9.3 for ; Thu, 10 Sep 2026 06:14:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789046046; x=1789650846; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=0RBdCvOXR8GdbPGyu0+w4vAq1GaMHqM0XN6uWGZwgMU=; b=PXWsHphjkbv3kMAKsdNgaaHCKXte7YlPMcMGmaSybfJTUfO91ZIsRt0xz5cW5tWs92 zkHb9KSkvoKABktLlzIwl99I8afgv+wdxFwYFdZctnihN9dyNxPeRM5athFLGlYSro2J PQqJrO5N3LBcIMke1cKFYW5cQ2IN5oLCEyW4FqW+m0x0ReVfN2nT6Z4PUo7RyBKPongQ 5BrOzpdyXtpXdJSAdSqdNZmV+GBRnEkl8iGVRs9qgbT1HfbsH8FRaXB03fVXXhINxF/x Ka/tY/bVtCbLCuNEHlv/HNdc4yJvIr09XWmL1JryTxeS13I4eAPScYZ76I5+gRdilbs3 7xFg== X-Gm-Message-State: AFuF++mdCB73u4+ks8xzDbIRryyWzMTyBC0It43eRUnEresjQY/gDo4d 8fcRpVPl5VlyB3QzB1VU3ArOwKqiVsy1CyLAtXK8qHflNBp+TH+HH06zNzM7ri3mLYmGIFjYIm0 nxLTAtG9Il1lUHDtlW0awY5dlVsa6aqCfi8Q0Vyxewxtdk/knYfz3jIgfNQ+cJbwRNEMIifqtrl RAmBywltC9DzXmYih2Y683l/xryCrFVXBldLdbGZnQw8sjshk= X-Gm-Gg: AYBFou2G78IBQN0yscCvFmuKCGFZ5LJsxJZU9pl75LcuRRgIpqVxlw5vNb221togrPq lVNtkY7GD8kpvtMHfhshqWEjZ/EGMulJk1lNQG1edj/n8NqvHv1b3kdv4s1sm2Kni/FfWapX0XS DUGysTU08kglOP0G2hmDEWQBohPOYDcpjjQetj5ErD5ulmczGfmDBNPx18yVgyrk+NNMBofpg+I NF/3Mx7Jv611pwgGUo4zYi38AJ1V1DLXHWHOuKBS1tD/3Ptg1MIw8PvvWm6zHpu5r9jozUMzgMX ZQBWhfb8G0Da5SRnl7oclllFl7jxsflTYx0BaumXNRpCQfnMzdfO3C19Qq/DyKU1yVKl5x5GW22 vrOHvqkoo+uobonS0 X-Received: by 2002:a05:600c:8012:b0:49c:d818:8764 with SMTP id 5b1f17b1804b1-49cf826818dmr427293355e9.11.1789046046082; Thu, 10 Sep 2026 06:14:06 -0700 (PDT) X-Received: by 2002:a05:600c:8012:b0:49c:d818:8764 with SMTP id 5b1f17b1804b1-49cf826818dmr427292655e9.11.1789046045525; Thu, 10 Sep 2026 06:14:05 -0700 (PDT) Received: from localhost (59.6.93.209.dyn.plus.net. [209.93.6.59]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-485883c074asm50440049f8f.23.2026.09.10.06.14.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 06:14:05 -0700 (PDT) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Tom de Vries , Abhay Kandpal , Andrew Burgess Subject: [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior Date: Thu, 10 Sep 2026 14:13:53 +0100 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: pRicwPZRas1BcmlK5u3uIGJiUv5lU4njREhqnHXsePM_1789046046 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit content-type: text/plain; charset="US-ASCII"; x-default=true 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 After commit: commit 32090b27e92cb8fd4998e8e8e65d43f445545bc7 Date: Wed Sep 2 10:43:34 2026 +0100 gdb: fix incorrect search domain in find_function_in_inferior Bug PR gdb/34602 was created which details some new regressions that were introduced for the tests: gdb.ada/funcall_ref.exp gdb.ada/arrayparam.exp gdb.compile/compile.exp gdb.compile/compile-cplus.exp The previous commit fixed the gdb.compile/ regressions, and this commit fixes the gdb.ada/ regressions. I initially struggled to reproduce this issue. The bug was reported against an openSUSE system, and in the end I was only able to reproduce it on a similar openSUSE system. I suspect this is related to the original reporter, and myself, not having a particular debug package installed. The tests in question need to allocate memory in the inferior. To do this they call value_allocate_space_in_inferior, this calls find_function_in_inferior, which after commit 32090b27e92cb8fd makes a successful call to lookup_symbol. This results in a backtrace like this: #0 ada_alias_get_block_value (sym=0x213da30) at ../../src/gdb/dwarf2/ada-imported.c:107 #1 0x0000000000db8775 in symbol::value_block (this=0x213da30) at ../../src/gdb/symtab.c:6619 #2 0x000000000045cc1f in remove_extra_symbols (syms=std::__debug::vector of length 2, capacity 2 = {...}) at ../../src/gdb/ada-lang.c:5182 #3 0x000000000045e236 in ada_lookup_symbol_list_worker (lookup_name=..., block=0x0, domain=..., full_search=true) at ../../src/gdb/ada-lang.c:5702 #4 0x000000000045e3c9 in ada_lookup_symbol_list (name=0x16a3ae4 "malloc", block=0x0, domain=...) at ../../src/gdb/ada-lang.c:5727 #5 0x000000000045e4bf in ada_lookup_symbol (name=0x16a3ae4 "malloc", block0=0x0, domain=...) at ../../src/gdb/ada-lang.c:5758 #6 0x000000000047b15a in ada_language::lookup_symbol_nonlocal (this=0x1bfd2c0 , name=0x16a3ae4 "malloc", block=0x0, domain=...) at ../../src/gdb/ada-lang.c:13839 #7 0x0000000000dac991 in lookup_symbol_aux (name=0x16a3ae4 "malloc", match_type=symbol_name_match_type::FULL, block=0x0, domain=..., language=language_ada, is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:2150 #8 0x0000000000dabfab in lookup_symbol_in_language (name=0x16a3ae4 "malloc", block=0x0, domain=..., lang=language_ada, is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:1961 #9 0x0000000000dac042 in lookup_symbol (name=0x16a3ae4 "malloc", block=0x0, domain=..., is_a_field_of_this=0x0) at ../../src/gdb/symtab.c:1974 #10 0x0000000000f36346 in find_function_in_inferior (name=0x16a3ae4 "malloc", objf_p=0x7fffffffbef8) at ../../src/gdb/valops.c:122 #11 0x0000000000f36542 in value_allocate_space_in_inferior (len=8) at ../../src/gdb/valops.c:186 If GDB is unable to find the Ada alias for the function to be called then an exception is thrown. This exception propagates all the way out of value_allocate_space_in_inferior, causing the allocation to fail, and as a consequence, the test to fail. My thinking here is that, if the lookup_symbol call throws an exception then we should catch this in find_function_in_inferior and ignore it. The find_function_in_inferior has a minimal symbol fallback path, so if the full symbol lookup throws an exception that doesn't mean we cannot try the minimal symbol path. That's what I have implemented here. With this done the gdb.ada/ tests are now passing on my openSUSE test machine. No new tests here as the original failure relies on being in an environment where there is insufficient debug information to find the Ada malloc function alias. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34602 --- gdb/valops.c | 31 ++++++++++++++++++++++--------- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/gdb/valops.c b/gdb/valops.c index 2ff15de7c68..a235a0ebe8d 100644 --- a/gdb/valops.c +++ b/gdb/valops.c @@ -112,21 +112,34 @@ show_overload_resolution (struct ui_file *file, int from_tty, struct value * find_function_in_inferior (const char *name, struct objfile **objf_p) { - struct block_symbol sym; bound_minimal_symbol msymbol; - sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN, nullptr); - if (sym.symbol != nullptr) + try { - msymbol = find_gnu_ifunc (sym.symbol); - if (msymbol.minsym == nullptr) + block_symbol sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN, + nullptr); + + if (sym.symbol != nullptr) { - if (objf_p != nullptr) - *objf_p = sym.symbol->objfile (); - return value_of_variable (sym.symbol, sym.block); + msymbol = find_gnu_ifunc (sym.symbol); + if (msymbol.minsym == nullptr) + { + if (objf_p != nullptr) + *objf_p = sym.symbol->objfile (); + return value_of_variable (sym.symbol, sym.block); + } } } - else + catch (const gdb_exception_error &) + { + /* Ignore the error. If there's a problem looking for the full + symbol then we shouldn't give up, we should fall back to + looking for the minimal symbol. */ + } + + /* If we didn't find an IFunc related minimal symbol above, then + look for a suitable minimal symbol now. */ + if (msymbol.minsym == nullptr) msymbol = lookup_minimal_symbol (current_program_space, name); if (msymbol.minsym != nullptr) -- 2.25.4