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

[Simon Marchi <simark@simark.ca>]

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