From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OTMrMueKPmqIUhkAWB0awg (envelope-from ) for ; Fri, 26 Jun 2026 10:21:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1782483687; bh=kGloeexeuCrT9+zKRsv0QjgnbpofCRMuC9bzqJylBtM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=mJImphjQyyXBcdVxPCEhjAf0fKsaIJWndlRyxJrT9Xfb27pRNduIOTGczxqH9ij5l kcQxbLfMiCOYPsMr21Y3IYflFSZQWeqgVI9dyYaJ5+VBcFNGjj7n1jEU0MAGvuXoMq qE1L8ELVfwKrw0upyJIV28qLxQ4FAoGsLA9EB5no= Received: by simark.ca (Postfix, from userid 112) id BD77B1E098; Fri, 26 Jun 2026 10:21:27 -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,RCVD_IN_MSPIKE_H2 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=mvR6Ay3C; 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 7A6A51E024 for ; Fri, 26 Jun 2026 10:21:25 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 91C644BA2E1B for ; Fri, 26 Jun 2026 14:21:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 91C644BA2E1B 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=mvR6Ay3C Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2884C4BA2E13 for ; Fri, 26 Jun 2026 14:20:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2884C4BA2E13 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 2884C4BA2E13 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=1782483655; cv=none; b=rIeI0RHyCeMoDEtC+GLvryF9FoSCft8FyHV5n6spvVplcb46+p3DDwHYFObSKi6txImZqka+sSPxvI1qnbMWZciLtQvSeCgI+WjBKdZP5HGNpY8lijiaa2B78jn6GuX6Uw+QYK4HKJ/v2q6edBTinqyKQVhtrRMiLgEexpgC9lM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782483655; c=relaxed/simple; bh=kGloeexeuCrT9+zKRsv0QjgnbpofCRMuC9bzqJylBtM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=t36efgjMNDvkqdqSv65400YaIsP+llkyw089esBBFOU7k6OSvgLJMzMUlhTr0GjXZ41Xq8qAVppUdohMNRcAb33B16zRqPy+acIvwHP1+VHhEEmz28IeIuFVOryoZ5YLiV73xDbaVx+h2mht8gwMvrjl+kDRJx1naJ/Jt+E9n4A= 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=mvR6Ay3C DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2884C4BA2E13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1782483653; bh=kGloeexeuCrT9+zKRsv0QjgnbpofCRMuC9bzqJylBtM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=mvR6Ay3CONNadvejnlIe6SQXjOG9Oum53u8T+R2KJgf2TX5x7RtE3cqNhtBZY4LqQ c/lzq2wTGll9TAs/P6Pgw4gAbaDErF8XxzUklGvs7vsjmS1ls4Tm/hehxJeFvJTLp9 s3TF/2J2GpOZHJ89M4Kupv872o+4eLCeNs41x9o8= Received: by simark.ca (Postfix) id AD5561E024; Fri, 26 Jun 2026 10:20:52 -0400 (EDT) Message-ID: <32de9d68-7f37-43b5-a0c9-cf26689f8946@simark.ca> Date: Fri, 26 Jun 2026 10:20:52 -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> <8deef437-9f69-4c18-a1fb-9a046608d046@arm.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <8deef437-9f69-4c18-a1fb-9a046608d046@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 On 2026-06-26 05:24, Muhammad Kamran wrote: > Hi Simon, > > On 25/06/2026 21:05, Simon Marchi wrote: >> >>> @@ -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. >> > > I've extended the test to run through the existing > resolver_attr/resolver_debug/final_debug matrix. With only the test > change, the new inferior-call test fails in all eight combinations on > AArch64, so the issue is wider than the original no-debug minimal-symbol > case. I'll work on the patch accordingly and post a new version once I > have the patch ready. > >>> 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 used find_minsym_type_and_address because it keeps > find_function_in_inferior consistent with normal minimal-symbol > evaluation. It also handles function-descriptor symbols: > mst_data_gnu_ifunc may have a descriptor address as its value, and > find_minsym_type_and_address can convert that to the code address and > reclassify it as mst_text_gnu_ifunc. A direct mst_text_gnu_ifunc check > would miss that case, and value_address () could be the descriptor > address rather than the callable address. > For reference: gdb/minsyms.c:1594 has: > /* The minimal symbol might point to a function descriptor; > resolve it to the actual code address instead. */ > > If you still prefer avoiding find_minsym_type_and_address here, I think > we would need a helper that shares the same descriptor/address handling, > rather than checking only mst_text_gnu_ifunc. If the descriptor to actual address translation is really needed, then find_minsym_type_and_address sounds fine. Simon