From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YcPGKbeSQmpU+x0AWB0awg (envelope-from ) for ; Mon, 29 Jun 2026 11:43:51 -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=qM2wj3Fa; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9F9CC1E024; Mon, 29 Jun 2026 11:43:51 -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 [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 BE80B1E024 for ; Mon, 29 Jun 2026 11:43:50 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EB4064BA2E3E for ; Mon, 29 Jun 2026 15:43:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EB4064BA2E3E 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=qM2wj3Fa Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id AC0204BA2E04 for ; Mon, 29 Jun 2026 15:43:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC0204BA2E04 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 AC0204BA2E04 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=1782747805; cv=none; b=cFTVaXAGO2dOG2Hj09w4t8vI89bOHLqapcNi2lDcSW0z6V34VxUBlI4XHNuWwHzFvqZRe3c82xzHSGnY7Nxo6yGfJdyHIv7Imvte/rkT5F9RjwZnpNLNzwM4igCL3LX8nL6Qlh9V4BRHdiL1vVqGE1ockYZMJzSnm1Q5UrIWzs8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782747805; c=relaxed/simple; bh=7DjGmmfF8lkM5pB4Tk7h7UqLWu4Or0jNz62vphuFxm4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ubMsb5a3KHob/drqkcHO+C0T1t26lTQgJV080fPE/uZENxutGLBw048X0SI3hM6hHLOJC99xI2Nn9ibZAHU5B/fAjSy3yizz3gRTeaouQmrhlikU425TMZks/MvRBCHPdZm2/1FvSzlY/dvgddTnyzKPeFIFCY3Od9ZTmqZt9u4= 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=qM2wj3Fa DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC0204BA2E04 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 BA1901D31; Mon, 29 Jun 2026 08:43:20 -0700 (PDT) Received: from [10.1.29.172] (K775M2XVT2.cambridge.arm.com [10.1.29.172]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 07DE93F673; Mon, 29 Jun 2026 08:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782747805; bh=7DjGmmfF8lkM5pB4Tk7h7UqLWu4Or0jNz62vphuFxm4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qM2wj3FacHcGkvvW6VpCDB3xQeT23ymZv8oo0UdU5QbmUWa6H9lN2w1HG0thg3n3T OHJPEnKjo+FQZiw6MzyiBCGNuhDPf8gNBO8wjKBzfs0FbN7IeLo1SUWW3t+FfU9dUW YugIEayrkgU5AQ3XM7mMs+MFPvxq5WUfcpUZoZGs= Message-ID: Date: Mon, 29 Jun 2026 16:43:22 +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> <8deef437-9f69-4c18-a1fb-9a046608d046@arm.com> <32de9d68-7f37-43b5-a0c9-cf26689f8946@simark.ca> Content-Language: en-GB From: Muhammad Kamran In-Reply-To: <32de9d68-7f37-43b5-a0c9-cf26689f8946@simark.ca> 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 26/06/2026 15:20, Simon Marchi wrote: > > > 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 posted a v3 using the direct minimal-symbol type check you suggested. That is better here because find_function_in_inferior only needs to preserve the IFUNC marker on the synthetic function type; it does not need to redo minimal-symbol address/type resolution. The descriptor case is already handled later in the normal inferior-call path. find_function_in_inferior creates a pointer-to-function value, and find_function_addr handles such values by calling gdbarch_convert_from_func_ptr_addr before IFUNC resolution. Thanks, Kamran >> >> 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