From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nxXaI6ixR2q0syMAWB0awg (envelope-from ) for ; Fri, 03 Jul 2026 08:57:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1783083432; bh=qLZoY3zsQHz4AVT6cesIfQjgCmh6dHo/FDco9ELmQWg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=GBvxRaKYZiG6dI569UOILgoqz4+K3ek26Z4Lb4RAKp2Kj0+trRCkx4G/fCowTuv/B 3cDSV/6dwPSeKYpT0obWzAymc0IjVbwY5s9nlztEFPrUz6HmLIpitqnXMVDyawoH/E eLmcdhkr2fnGJJ7dldJfwTwh/0nc3u4yGZwqdQOg= Received: by simark.ca (Postfix, from userid 112) id 8977F1E098; Fri, 03 Jul 2026 08:57:12 -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 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=AEUUr0/u; dkim-atps=neutral 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 E74AC1E024 for ; Fri, 03 Jul 2026 08:57:11 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 849FB4BA2E1A for ; Fri, 3 Jul 2026 12:57:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 849FB4BA2E1A 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=AEUUr0/u Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 172944BA2E10 for ; Fri, 3 Jul 2026 12:56:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 172944BA2E10 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 172944BA2E10 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=1783083407; cv=none; b=lHA11N3ftCejYSvqN/M0f50Bz6acI7uIeeTBQLJtBSiIqodw98TIY6cKQuBpJzNvJSn5cE/TCub9Z0Q1Qz6ZqslEZd0YUVFa/nAWiIFRIXdQq4/NMvZ/3BMfneNtK4HTRTTuE5sB0w/MSxUEKcigJ65/s8NOxxsygZAMYJ+TXKo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783083407; c=relaxed/simple; bh=qLZoY3zsQHz4AVT6cesIfQjgCmh6dHo/FDco9ELmQWg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=YGLyLerX9tL60YjIgulKPno4loFjcjPXYy+nk3OR5LW0Yv8EetRZXXyu00jtyslq4Ogy44Ga7cY697imINjOFvtBJpEbhb6gwxrmhNJuJdr8QvulOn6ZcL51OmreaMT+eB12WpqeG72sdbcbBwI052kgVZpnbr7Nlq75BRzRr6c= 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=AEUUr0/u DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 172944BA2E10 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1783083405; bh=qLZoY3zsQHz4AVT6cesIfQjgCmh6dHo/FDco9ELmQWg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=AEUUr0/u4bzlabGBWDzr1JQydpIeVjY7zB7jogkv5b71g3hvamW/5DXNwpqFEiH32 x0SHew3atF0PUMdKGN0MKL6u5zH1NlAph3+WC5EUGNNm2exM98fq9Sgqz+6FUreGcE y5aZo9ejX17hw66QPu+TRcuUIppcvy+x5hS5FmW8= Received: by simark.ca (Postfix) id AC6B51E024; Fri, 03 Jul 2026 08:56:44 -0400 (EDT) Message-ID: Date: Fri, 3 Jul 2026 08:56:44 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/1] gdb: Preserve IFUNC marker when finding inferior functions To: Wilco Dijkstra , Muhammad Kamran , Florian Weimer Cc: "gdb-patches@sourceware.org" , Andrew Burgess , 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> <549b8d25-1102-42bc-96d0-24ac30060ea0@arm.com> Content-Language: fr From: Simon Marchi In-Reply-To: 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 6/30/26 11:29 AM, Wilco Dijkstra wrote: > Hi Muhammad, > >> 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. > > Indeed - while the patch works for now as a workaround, directly calling > ifunc resolvers without following the ifunc ABI does not work. GDB only > passes HWCAP as the first argument, so the resolver may return different > functions due to the set of HWCAP values given not being identical between > GDB and GLIBC (ie. It could call the wrong malloc implementation that was > not selected or initialized). > > So the best option is to call dlsym() as Florian suggested. To track this, could either of you file a GDB bug with the necessary background (why it would be good to switch to using to dlsym to resolve ifuncs)? Thanks, Simon