From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +F3gEGm/PWqNeBgAWB0awg (envelope-from ) for ; Thu, 25 Jun 2026 19:53:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1782431593; bh=XKRmf2WoXkdSMHyNi1rgJDhugzQn0RhlSlTWHlNRctM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Y5pU6K8hxB0gihalVou5+ac/R3T8phsOfkrqQ/iW73Cnul6Q5a/C/MQ1k7EaDPpTB 9/lH/pa4AGZpslSr/m2X2a2tvRBjSoXbRL7fBXwkLctlCsTBH32nLNXicqaRZbEUIs FbEq2n4xtC9cnvivAHXHDWeGBtbAFMmn5McvgetA= Received: by simark.ca (Postfix, from userid 112) id 3364D1E098; Thu, 25 Jun 2026 19:53:13 -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=kdBDXGZi; dkim-atps=neutral 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 52E911E070 for ; Thu, 25 Jun 2026 19:53:12 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 64B0A4BA23D8 for ; Thu, 25 Jun 2026 23:53:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64B0A4BA23D8 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=kdBDXGZi Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 20C084BA23C5 for ; Thu, 25 Jun 2026 23:52:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 20C084BA23C5 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 20C084BA23C5 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=1782431564; cv=none; b=XHYqLTSduzLcik7pcDkZeZYo8An82Otr2R2yxW841f3Y+LZ6n9AhNgmJx6pfHinJMy8uYbDFi2vExrCXIu7SRJ0z+ar9l0p1EYnsR8BbAm1Dv2AKx9E6rNeGoQlB3JafA/306m12jAnbvMb4emWm6jqa87C4EuIf5OwHXRb/1+Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782431564; c=relaxed/simple; bh=XKRmf2WoXkdSMHyNi1rgJDhugzQn0RhlSlTWHlNRctM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=JWY/AuJ4/kh9ey2HG+CLZDcx8JCTD9Momx/3dOuQrMW58ImJvgRaSuM0mawje75laoYQY6ka6WuLA2hkfaVJ/PWleocapjdBDSqRNOM+0y3XXjYGrAXzDKYZqMYRayZCmGKp+8d6RzbTTtjgBXpHUZpp16J39aQ2WDR1X0EWKAE= 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=kdBDXGZi DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 20C084BA23C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1782431561; bh=XKRmf2WoXkdSMHyNi1rgJDhugzQn0RhlSlTWHlNRctM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kdBDXGZife3PFpdBLuOF0CJDLdvgpkguRM2zy+jS+AWMfb0YGKnvCXMsucAE+Lgp8 YnPcIL74mqfmeBM0bttfab0wlv468NT131p7MG9VdZY5eUMjPGsAHUoo0JEDVNKlpf R5NSeviRfdyL57rWsYaWsmKfxj+zpN/ITha1JHnE= Received: by simark.ca (Postfix) id BE0261E070; Thu, 25 Jun 2026 19:52:40 -0400 (EDT) Message-ID: Date: Thu, 25 Jun 2026 19:52:40 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/1] gdb: Preserve IFUNC marker when finding inferior functions To: Carlos O'Donell , Yury Khrustalev , Muhammad Kamran Cc: gdb-patches@sourceware.org, Wilco Dijkstra , Thiago Jung Bauermann , Adhemerval Zanella Netto References: <20260624095002.5247-1-muhammad.kamran@arm.com> <9f0013bd-f19a-44be-a90d-788c078bfba6@simark.ca> <050c1813-98cd-4fdf-a629-11ffa9ce9858@redhat.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <050c1813-98cd-4fdf-a629-11ffa9ce9858@redhat.com> 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 2026-06-25 19:08, Carlos O'Donell wrote: > On 6/25/26 4:16 PM, Simon Marchi wrote: >> >> >> On 2026-06-24 08:56, Yury Khrustalev wrote: >>> On Wed, Jun 24, 2026 at 09:50:01AM +0000, Muhammad Kamran wrote: >>>> This patch fixes a GDB inferior-call issue exposed by malloc being a GNU >>>> IFUNC in glibc on AArch64. >>>> >>>> GDB calls find_function_in_inferior ("malloc") when expression evaluation >>>> needs to allocate memory in the inferior, for example for string literal >>>> arguments. In the minimal-symbol fallback, GDB created a synthetic ordinary >>>> function pointer from the minimal symbol address. If the symbol was a GNU >>>> IFUNC, this lost the IFUNC marker, so call_function_by_hand did not >>>> resolve the symbol before calling it. >>>> >>>> The patch uses find_minsym_type_and_address to classify the minimal symbol >>>> and propagates the IFUNC marker to the synthetic function type when needed. >>>> The existing fallback return type is unchanged. >>> >>> Thanks! I confirm that all GDB testsuites that showed regressions now >>> pass with Glibc from master and this patch applied on top of GDB master. >>> >>>> >>>> Should this be considered for backporting to release branches? >>> >>> Yes please, at least GDB 16.x and 17.x I think should be covered. >> >> The bugfix release of GDB 17 (17.2) has already been released, we have >> historically not done more than one bugfix release of a given release >> branch (just a handful of special cases where we noticed the release was >> completely broken, just after releasing it). We usually just move on to >> working on the next release (18, in this case). >> >> As the new co-release manager (along with Andrew), I would be open to >> discuss changing this, to allow having as many bugfix releases on a >> stable branch as needed, at least until the following major version is >> available. But I have not done a release myself yet, so I'd like to >> wait to see how it's actually like before deciding. > > Has gdb ever considered a rolling release branch model like glibc? > > In glibc we acknowledged that the major consumers could and would like > a release branch that is basically rolling with fixes, while we do cut > an official X.Y release, after that the release branch rolls forward > with each commit valid and containing an additional fix. I think that's pretty much the case already, we only commit necessary fixes to the the release branches, so it is always in a working and usable state (to the best of our knowledge). We just don't advertise each individual commit as being a "release". Simon