Re: [PATCH 0/1] gdb: Preserve IFUNC marker when finding inferior functions

[Carlos O'Donell <carlos@redhat.com>]

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.

> In the mean time, it's always possible to push a fix to the
> gdb-17-branch (and even the gdb-16-branch) without it being part of a
> release.  Downstream packagers can then take this commit and carry it as
> a local patch.
I like this idea, what I was trying to express above was that the project
could also pinky-swear not to leave the branch in a broken state such
that it is considered a rolling working release until the next point
release.

In glibc we did away with point releases, they were too much work and
downstream was just as happy to "git pull --rebase" from the release
branch.

Granted the release branch should have some rules, like no backporting
of things that break ABI, API, or exiting commands etc. etc.

-- 
Cheers,
Carlos.