From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dBntKl1LPWor/hcAWB0awg (envelope-from ) for ; Thu, 25 Jun 2026 11:38: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=Us+pTqv1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A01791E098; Thu, 25 Jun 2026 11:38: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=ham 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 5E7441E024 for ; Thu, 25 Jun 2026 11:38:04 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5A0704BA23DD for ; Thu, 25 Jun 2026 15:38:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5A0704BA23DD 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=Us+pTqv1 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id EF0ED4BA2E1B for ; Thu, 25 Jun 2026 15:37:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EF0ED4BA2E1B 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 EF0ED4BA2E1B 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=1782401859; cv=none; b=XEYmG9YJ5EvQ1iz6K18GLBZ9gilZWgUzn7IQ8x4pzncd94RAPgrINgCH7Dl+G2bhWJGUZdXoPHzGHJU17N9E4vmBRoewPD8JNhu3bmsvERQT85y6ztJjNyo0LATeRom+J6f8MWNpGMsLZ7jT4CoXigJUp4lOTWk1neFUGRP/G4k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782401859; c=relaxed/simple; bh=wLDh461EF82XJAlb7Mlrhc/ieNneXbAdXlaaP2Bl86w=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JxgNG0tdTI1M9AAA5mFmSICB+QIIomErGOOrV5T9PSiH2TGHPdQOnPPchRW33HYv72kW6i5qRr9JI8EOBFtfiWjJ1ulV3eEBRkkQ5OvEQE0az/fHOhQZUCV79iYxtiO1SgEBUk6jX2k2XRVsM4pd04RMmqZXnwkxBtuqHqlbZAE= 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=Us+pTqv1 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EF0ED4BA2E1B 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 E49F325E4; Thu, 25 Jun 2026 08:37:33 -0700 (PDT) Received: from [10.1.29.167] (K775M2XVT2.cambridge.arm.com [10.1.29.167]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E7F43F632; Thu, 25 Jun 2026 08:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782401858; bh=wLDh461EF82XJAlb7Mlrhc/ieNneXbAdXlaaP2Bl86w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Us+pTqv1nD1GaTQU8NR9ftitEUf/3bcvpPa6MUoil26d4oewbGv8ip3F4muXpyYdi kbU859pzj0Rwya7RupSyma9wtuPFvHdP1chYWJEUB6pRmjHrTgKS8YFnB4ml3wdKR2 J7BAu/YqyzQUDCY1qc/IbFG83VOFs2prKpf2MilU= Message-ID: <2f662f00-f4ed-4910-aa58-5a82e6b9f075@arm.com> Date: Thu, 25 Jun 2026 16:37:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] gdb: Preserve IFUNC marker when finding inferior functions To: Andrew Burgess , gdb-patches@sourceware.org Cc: Wilco Dijkstra , Yury Khrustalev , Thiago Jung Bauermann , Adhemerval Zanella Netto , Carlos O'Donell References: <20260624095002.5247-1-muhammad.kamran@arm.com> <20260624095002.5247-2-muhammad.kamran@arm.com> <87o6h0ndd6.fsf@redhat.com> Content-Language: en-GB From: Muhammad Kamran In-Reply-To: <87o6h0ndd6.fsf@redhat.com> 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 Andrew, Thanks for the review. On 24/06/2026 16:53, Andrew Burgess wrote: > Muhammad Kamran writes: > >> GDB calls find_function_in_inferior ("malloc") when expression >> evaluation needs to allocate memory in the inferior, e.g. for string >> literal arguments. >> >> The minimal-symbol fallback created a synthetic ordinary function >> pointer from msymbol.value_address (). If the symbol was a GNU IFUNC, >> this discarded the IFUNC marker, so call_function_by_hand did not >> resolve the symbol before calling it. >> >> Use find_minsym_type_and_address to classify the minimal symbol and >> propagate the GNU IFUNC marker to the synthetic function type. This >> keeps the existing fallback return type while allowing inferior calls >> through IFUNC symbols to be resolved correctly. >> --- >> gdb/valops.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) > > Is it possible to create a test for this issue that would fail on other > targets? There's gdb.base/gnu-ifunc.exp, from the patch I'm wondering > if all that would be needed is to place an ifunc function in a library, > and compile the library without debug information? It's not super clear > from your description the exact steps that are needed to trigger this > bug. Yes, this can be tested. I added a regression test in v2 to gdb.base/gnu-ifunc.exp. The test defines malloc as a GNU IFUNC in a no-debug object, and links it with a small debug test program. The test then evaluates an inferior call with a string literal argument. Copying that string literal into the inferior forces GDB through find_function_in_inferior ("malloc"), which exercises the minimal-symbol fallback. > >> >> 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); > > There are other places in GDB where we use lookup_function_type, could > these also run into this issue? It would be nice if the description > explained why other similar places in GDB don't need changing if that's > the case. The issue is not lookup_function_type itself. The bug fixed here is the specific find_function_in_inferior minimal-symbol fallback: it had already found a minimal symbol, but then built a synthetic callable value without carrying over the symbol's STT_GNU_IFUNC classification. I did not find another direct lookup_function_type caller with the same minimal-symbol fallback pattern. Some code does build ordinary function pointer types for known non-IFUNC helper paths, so I have kept this patch limited to the path needed by find_function_in_inferior. Thanks, Kamran > > Thanks, > Andrew > > >> >> if (objf_p) >> *objf_p = objfile; >> -- >> 2.43.0 >