From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rtuhNB2KPWrIQxgAWB0awg (envelope-from ) for ; Thu, 25 Jun 2026 16:05:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1782417949; bh=PsN+S/s4K6MLgO5J9t5ESUgHuAIbOC+DjzNHX4DN/p0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=ETi/1JjdykyzTosGlZ01DMPhtQv5Iu6ZPymoNqgHX32swRHk1ApQ4gopJJd469v0f HLvcaGMuWIfMFnuo3EmkM/K62gvDvpah+92Qymv/ORtCMNAoRp4To5JnXewpWwiglI gexn8htJkt1UUM2K7AR4CXbYSoxAwqAr4qz60dYU= Received: by simark.ca (Postfix, from userid 112) id C9A391E0A6; Thu, 25 Jun 2026 16:05:49 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=pXO0BRo5; dkim-atps=neutral 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 0A9271E090 for ; Thu, 25 Jun 2026 16:05:49 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 828394BA23C5 for ; Thu, 25 Jun 2026 20:05:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 828394BA23C5 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=pXO0BRo5 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C8ACD4BA2E17 for ; Thu, 25 Jun 2026 20:05:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C8ACD4BA2E17 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C8ACD4BA2E17 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782417923; cv=none; b=gWe8lXwJ82NFRX3qztTRcT9GebG2QzOQYzDuYvYxua4po19xFarEG+TCGwAlzCCcDWKk6ez/OYh01o1HQ0VZnQ3k0F6wTjI+ZLb2GnrNi5oRr1JyyGPiEKwM7NYM/mndflELsfaq3+fS/6Tp9LAEt7F4DrIVIZ+d339vrkDpmKY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782417923; c=relaxed/simple; bh=PsN+S/s4K6MLgO5J9t5ESUgHuAIbOC+DjzNHX4DN/p0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=WBSge2YIvz/tBNoM/Y457wVnWv+jhjLQpWU/aVjJARoZ5658hGJRqfObHrA4+Rfu3WhtTMy5Mr4Folqwf8JEBSC2qY0vgkBmpbfsCdW2ue+lrPmBYs/l7IBFpfsYrJrgHRKKtW/gXzdHV+EthBha2YUGWbMIC+M+LRLAdFuZM7o= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=pXO0BRo5 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C8ACD4BA2E17 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1782417922; bh=PsN+S/s4K6MLgO5J9t5ESUgHuAIbOC+DjzNHX4DN/p0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=pXO0BRo575/0k/p3/h899V6+zdlgyIw3GH0Jvt3tS+wQ1vB5bNQMmuJuudZ62z2jl gOTLBHQFkkTPZ9cqSuAqrMTVNYsSct4RT4OQx4tqc67BUmcQgfpBfbeobyl8jV9TU2 4RckBx3vmxE3ahO4MNb2nVPh9GihHYPTsfIMZFp8= Received: by simark.ca (Postfix) id 8DD301E070; Thu, 25 Jun 2026 16:05:21 -0400 (EDT) Message-ID: Date: Thu, 25 Jun 2026 16:05:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] gdb: Preserve IFUNC marker when finding inferior functions To: Muhammad Kamran , gdb-patches@sourceware.org Cc: Andrew Burgess , Wilco Dijkstra , Yury Khrustalev , Thiago Jung Bauermann , Adhemerval Zanella Netto , Carlos O'Donell References: <20260625152036.6149-1-muhammad.kamran@arm.com> <20260625152036.6149-2-muhammad.kamran@arm.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <20260625152036.6149-2-muhammad.kamran@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 > @@ -356,6 +361,39 @@ proc misc_tests {resolver_attr resolver_debug final_debug} { > } > } > > +# Test that GDB resolves a GNU IFUNC minimal symbol when it uses > +# find_function_in_inferior to make an internal inferior call. String > +# literals are copied into the inferior with a call to malloc, so a > +# no-debug IFUNC malloc exercises the minimal-symbol fallback. > + > +proc_with_prefix test_inferior_call {} { > + global srcdir subdir > + global infcall_file infcall_src > + global infcall_malloc_file infcall_malloc_src > + > + set executable $infcall_file > + set binfile [standard_output_file $executable] > + set malloc_obj [standard_output_file ${infcall_malloc_file}.o] > + > + if { [gdb_compile ${srcdir}/${subdir}/${infcall_malloc_src} \ > + $malloc_obj object {}] != "" > + || [gdb_compile [list ${srcdir}/${subdir}/${infcall_src} \ > + $malloc_obj] \ > + $binfile executable {debug}] != "" } { > + untested "failed to compile inferior call testcase" > + return > + } I think that the test should also cover the case where we do have debug info. However, the gdb.base/gnu-ifunc.exp test is already written in a such a way that it tests all imaginable combinations: # Test all the combinations of: # # - An ifunc resolver with the same name as the ifunc symbol vs an # ifunc resolver with a different name as the ifunc symbol. # # - ifunc resolver compiled with and without debug info. This ensures # that GDB understands that a function not a regular function by # looking at the STT_GNU_IFUNC type in the elf symbols. DWARF has # no way to express the STT_GNU_IFUNC type. # # - ifunc target function (resolved) compiled with and without debug # info. foreach_with_prefix resolver_attr {0 1} { foreach_with_prefix resolver_debug {0 1} { foreach_with_prefix final_debug {0 1} { if { [build $resolver_attr $resolver_debug $final_debug] != 0 } { misc_tests $resolver_attr $resolver_debug $final_debug set-break $resolver_attr $resolver_debug $final_debug } } } } Could you somehow hook the new infcall tests into that, so that we also test infcalls in all imaginable situations. > diff --git a/gdb/valops.c b/gdb/valops.c > index ab6fd5079e1..7d305871efc 100644 > --- a/gdb/valops.c > +++ b/gdb/valops.c > @@ -133,11 +133,15 @@ find_function_in_inferior (const char *name, struct objfile **objf_p) > struct gdbarch *gdbarch = objfile->arch (); > > struct type *type; > + struct type *resolved_type; > CORE_ADDR maddr; > type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char); > type = lookup_function_type (type); > type = lookup_pointer_type (type); > - maddr = msymbol.value_address (); > + resolved_type = find_minsym_type_and_address (msymbol.minsym, objfile, > + &maddr); > + if (resolved_type->is_gnu_ifunc ()) > + type->target_type ()->set_is_gnu_ifunc (true); Calling find_minsym_type_and_address just to know if the minsym is an ifunc seems rather heavyweight for nothing. Can't we just check that the minsym type is mst_text_gnu_ifunc? I assume that the `maddr` output by find_minsym_type_and_address would always be equal to `msymbol.value_address ()`. Side-note: this "find_function_in_inferior" (at least the fallback) really assumes that we are looking for a function returning "char *", so that function seems misnamed (it could easily be mis-used). Simon