From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id C3fPOonPQ2qMcR8AWB0awg (envelope-from ) for ; Tue, 30 Jun 2026 10:15:37 -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=l7MAYMmZ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D3DBB1E098; Tue, 30 Jun 2026 10:15:37 -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 74E331E024 for ; Tue, 30 Jun 2026 10:15:36 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0E9F74BA23D0 for ; Tue, 30 Jun 2026 14:15:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0E9F74BA23D0 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=l7MAYMmZ Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id D525B4BA2E10 for ; Tue, 30 Jun 2026 14:15:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D525B4BA2E10 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 D525B4BA2E10 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=1782828911; cv=none; b=Q+GZw52pqs2MKAVGtHq7R1KGEa1F7T8ZGXENdWuG+1QzHVPbvqtgzxV5DqU98dabAFLv+NeaRZhcdviMKznJB3F8oWTFj4ZXaSZTwAoUT1f9vTxM9BszSLKcNmGj2e0GQuUuSIYU8ZG9Cd8M9KSk8pf4jgwFSscNl/cbQ1xlwsU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782828911; c=relaxed/simple; bh=OBCP637xBXZNpv9/IhR2l63RpTk7PAaTXlfOSoKAulE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=SBYyWO8x/V+vSYZUmL5oNF0WZYdfvxpDqRWBdLY/WGjcpIaHNivgYImDTPUIqLjH0B8ps3Jfwq5A7cGx6VWd4zownvqQWvpizCJ4Q7ky2nSJsL/gCr9GdyNDvUyGta8j+ou+IhM886IbbSkMvWqk6Jlgf2YvinJ3NCF845QpwEc= 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=l7MAYMmZ DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D525B4BA2E10 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 872E92ED2; Tue, 30 Jun 2026 07:15:05 -0700 (PDT) Received: from [10.1.29.184] (K775M2XVT2.cambridge.arm.com [10.1.29.184]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 92E283F85F; Tue, 30 Jun 2026 07:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782828909; bh=OBCP637xBXZNpv9/IhR2l63RpTk7PAaTXlfOSoKAulE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=l7MAYMmZr+nj+GRtWXo6/Yg1rGycYmDtbzOqwidyo/PcZnNqdMChAtp5z8IxKqVQD FeImeLE6/x9YdGyvrlbkEnXmTNItEcmx8lFHwQ1eFiQstz1ifwdtuiS3UZIjFWnIz9 c6FsFxzjdriPCRXPiE69kZlPGZY+nrA0iIhVUKO4= Message-ID: <549b8d25-1102-42bc-96d0-24ac30060ea0@arm.com> Date: Tue, 30 Jun 2026 15:15:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] gdb: Preserve IFUNC marker when finding inferior functions To: Florian Weimer Cc: gdb-patches@sourceware.org, 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 Florian, >> GDB calls find_function_in_inferior ("malloc") when expression >> evaluation needs to allocate memory in the inferior, e.g. for string >> literal arguments. > > So this looks fairly nasty. This looks fairly harmless as far as GDB > expressions go: > >> + gdb_test "print (get_string (\"hello-ifunc\"), str_in_arena ())" \ > > We can actually detect the GDB call and glibc and do the right thing: > > [PATCH 0/2] Work around GDB bug overwriting __libc_malloc > > > Of course the GDB bug still needs fixing. > > By the way, I don't think there is a safe way for GDB to call IFUNC > resolvers. IFUNC resolvers in glibc may assume the presence of extra > data that was not there in the initial definition of the interface. > This shouldn't matter for malloc: elf_gnu_ifunc_resolve_by_got should > always be able obtain the pre-relocated address (except before > relocation has happened). Yes. GDB should prefer the cache/GOT path and avoid resolver calls where possible. The patch does not make resolver calls safer or add a new resolver-calling mechanism; it just preserves the IFUNC marker so the existing IFUNC resolution path is used instead of calling the resolver address as though it were malloc itself. > > Does your patch change the behavior and output of this? > > (gdb) print strcpy > $1 = {} 0x7ffff7e0b8f0 > > Currently, the workaround looks like this: > > (gdb) print dlsym(0, "strcpy") > $2 = (void *) 0x7ffff7ecb970 <__strcpy_avx2> > No. `print strcpy` uses the normal minimal-symbol evaluation path, which already classifies GNU IFUNC symbols. The patch only changes find_function_in_inferior's internal fallback path. I verified this on x86-64 with the patch applied and the output remains unchanged. Thanks, Kamran > Maybe going through dlsym would also be the right way to do the inferior > calls involving IFUNC resolvers. We can also provide a symbol that GDB > can call to make the IFUNC resolver call, given its handler address. > > Thanks, > Florian >