From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZBsWJOlFPmpvBBkAWB0awg (envelope-from ) for ; Fri, 26 Jun 2026 05:27:05 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=W9874k3D; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 87DD01E024; Fri, 26 Jun 2026 05:27:05 -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.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable 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 B75F31E024 for ; Fri, 26 Jun 2026 05:27:04 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0FEB84BA79BA for ; Fri, 26 Jun 2026 09:27:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FEB84BA79BA Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=W9874k3D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 2D3644BA23F2 for ; Fri, 26 Jun 2026 09:24:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D3644BA23F2 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2D3644BA23F2 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782465862; cv=none; b=CgL6DndhCCfsynWg4s0BbmDDU7VxYhSHO9rxtLeOr4+qTMhd3pP+yn57uHPqOkcw8Od2d4YtjdssrHGSmLKGY40MP6hdCJuD+jwaQ3zOBHVqjWMUxuciIDekp22hkauYaKH77OQjf7u0pcUztWiFl94zmwaP7PtXWIIWrEvx2tE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782465862; c=relaxed/simple; bh=jJh6XwddHXypFxdZp6x7q+2Vcp7qMPpL1/15AIw/vnQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ZX76Dz551sHpe7lZWElG8Bctaub8AZIokD7IAIIUE8eAQ+52hrP7uGEwneBAFeyq0z+YBXbCmYjUJ0u60/m5lbIPYXhZ3gRSZOdCmROMWSFwL9X8JfkJNFX1Tdr4xeVqgdnyC+gN3cCiqVXVE6/vN3usTGzcT8ezZz5oDEF3CYg= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=foss header.b=W9874k3D DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2D3644BA23F2 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D2AC31A9A; Fri, 26 Jun 2026 02:24:16 -0700 (PDT) Received: from [10.1.29.149] (K775M2XVT2.cambridge.arm.com [10.1.29.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 363CD3F836; Fri, 26 Jun 2026 02:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782465861; bh=jJh6XwddHXypFxdZp6x7q+2Vcp7qMPpL1/15AIw/vnQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=W9874k3DEay2uWzvjOGCucFxJgSwndJlbCWYqsnhlXSenQukv/ucqEOD+bwCRrwD1 qDNTurCrSEPOkurgCL3apwBuNUnuRPqVDMXAwrTIm1BwkRXDy0dZwL41c2U7KwzjOg mYQpO8ipjLN2MdeZUMk37iynGfFPKHNqUgMwmYEg= Message-ID: <8deef437-9f69-4c18-a1fb-9a046608d046@arm.com> Date: Fri, 26 Jun 2026 10:24:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] gdb: Preserve IFUNC marker when finding inferior functions To: Simon Marchi , 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-GB From: Muhammad Kamran In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed 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 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. Please share your thoughts. Thanks, Kamran > 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