From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AbSuFyjho2qXjT8AWB0awg (envelope-from ) for ; Fri, 11 Sep 2026 07:08:24 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=TCVHW9Br; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=zcKX2TRy; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=Xre00Mda; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=dKTci9gz; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4E6881E091; Fri, 11 Sep 2026 07:08:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 BDD441E091 for ; Fri, 11 Sep 2026 07:08:22 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 529FB51A3BAF for ; Fri, 11 Sep 2026 11:08:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 529FB51A3BAF Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=TCVHW9Br; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=zcKX2TRy; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=Xre00Mda; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=dKTci9gz Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id AFB0951A3B97 for ; Fri, 11 Sep 2026 11:07:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AFB0951A3B97 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AFB0951A3B97 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789124868; cv=none; b=W4A43EftgblWzr/JFEI4oYuWrga3i6OPB1527JpXNSkNLGRNUhWWEx7k7gZtwBx2jw9gQrmpKzVyUpmCkjctTnnKc6Ed+i6eNlaVIYgXqdr0KW5KENt0VtaxScNqU7A0pZ9UxjGR+KFXhEQRwm9kXrZkDMaIVpf68CCv5nsPOTs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789124868; c=relaxed/simple; bh=fjuGQ12GLdlIfJFRmtQAPvEwRppgk/jA+f7Pq4WxvXM=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=gUuKqvyu7XEzz9cf+Fkd7mra1hplfW87N2R9iRJphqGDVqXHmNvQbjftL9f5K2b2zDr4DZVnWL8YfwgY9PEdGBxTDWQqxTpfc7cLG1+iru0vgOnJac3PUMQ2yzmTFb2cUvCQcVrS69N/KA6v1/eEqJ25oqjyZerR6KEz0MafgcA= ARC-Authentication-Results: i=1; sourceware.org Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 5705E21C40; Fri, 11 Sep 2026 11:07:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789124861; h=from:from:reply-to: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=6OPVbHg/KAN7H38R5ppBri8bR3RZJZrmWerE4bmTwqo=; b=TCVHW9BrXYvURRZZ8S3HO5V6iWbgWUe2KJwQMV9HS3KCBb/4sNNBbqqwai7e+qoe0wfuwk 0NuINDC3ub05Q2RhyEtfnRQWsYruxy5XJoIbkeLF0eTiKVNp55LUcofA99lS4WmV2bLNmH XOn42/FpnQ9ElEFXVBb7JZhp7JDHgfw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789124861; h=from:from:reply-to: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=6OPVbHg/KAN7H38R5ppBri8bR3RZJZrmWerE4bmTwqo=; b=zcKX2TRyxYSB724PoUTv/P+FXen8or3/zBOBYVhsCwfeALMBvewWovEHL24bICvPIyM1gf LpxZcLyhR47206Dw== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=Xre00Mda; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=dKTci9gz DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1789124857; h=from:from:reply-to: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=6OPVbHg/KAN7H38R5ppBri8bR3RZJZrmWerE4bmTwqo=; b=Xre00MdaAz2hVYsGehFagGC+EEto2PP4qC1ebZa4JS6aSIYZVbuhjwConUgI+SbgAwpzXb zvF77xuy1xFYdSHRk7b/5X+JD4pBHSFXYeL8Q4M7iS1d15hI6tdEmnQxfm3G0ZpIyqiSmm sGOMac+340iHFFrIyvvj9P7c9HdAG9E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1789124857; h=from:from:reply-to: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=6OPVbHg/KAN7H38R5ppBri8bR3RZJZrmWerE4bmTwqo=; b=dKTci9gz+1Uppny3/u8EQUVhLYP+4KE9dmLT88L78ZrzrokqDS6LxNTenkqyLM4t3obyLa p9E0OZZjq+6TQ/Bg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 1439013715; Fri, 11 Sep 2026 11:07:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 8J9dAfngo2qKKgAAD6G6ig (envelope-from ); Fri, 11 Sep 2026 11:07:37 +0000 Message-ID: <5424362d-623e-459a-b06f-a0d9530c83dc@suse.de> Date: Fri, 11 Sep 2026 13:07:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior To: Andrew Burgess , gdb-patches@sourceware.org Cc: Abhay Kandpal , Tom Tromey References: Content-Language: en-US From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Queue-Id: 5705E21C40 X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,suse.de:dkim,suse.de:email,suse.de:mid]; DNSWL_BLOCKED(0.00)[2a07:de40:b281:104:10:150:64:97:from,2a07:de40:b281:106:10:150:64:167:received]; TO_MATCH_ENVRCPT_ALL(0.00)[]; URIBL_BLOCKED(0.00)[suse.de:dkim,suse.de:email,suse.de:mid,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo,sourceware.org:url]; DKIM_TRACE(0.00)[suse.de:+] 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 On 9/10/26 3:13 PM, Andrew Burgess wrote: > 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. > Hi Andrew, thanks for working on this. I've applied both patches and did a build and test run, and the regressions are fixed. > 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. > This is an interesting question, so I decided to investigate. The first thing I found was that the alias system.crtl.malloc == malloc is present due to extra debug info in the executable. FWIW, it comes from ./gcc/ada/libgnat/s-crtl.ads: ... function malloc (Size : size_t) return System.Address; pragma Import (C, malloc, "malloc"); ... In terms of debug info, the alias uses a DW_AT_linkage attribute to point to malloc. I found a test-case in the testsuite (gdb.ada/lang_switch.exp) that also uses pragma import, but in a simpler setup: unlike here the alias points to a function in the same executable. In case the c function is represented in the debug info, the alias target is found. Otherwise, not. This seems incorrect to me, so I filed a PR for this ( https://sourceware.org/bugzilla/show_bug.cgi?id=34627 ). Then the question, is debug info missing for malloc? That doesn't seem to be the case: ... $ gdb -q -batch outputs/gdb.ada/funcall_ref/foo-all -ex start \ -ex "set language c" -ex "p malloc" ... $1 = {void *(size_t)} 0x7ffff7d63d2e <__GI___libc_malloc> ... Looking at ada_alias_get_block_value, ISTM that using lookup_global_symbol means that it doesn't look beyond the exec containing the alias. So in conclusion, I'd say the debug information is present, but ignored. This might be due to a gdb bug, so I filed a PR ( https://sourceware.org/bugzilla/show_bug.cgi?id=34628 ). I haven't reviewed the patch in detail, but the idea sounds good to. Acked-By: Tom de Vries Thanks, - Tom > 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)