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

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

[Muhammad Kamran]

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.

Should this be considered for backporting to release branches?

Muhammad Kamran (1):
  gdb: Preserve IFUNC marker when finding inferior functions

 gdb/valops.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.43.0

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

[Muhammad Kamran]

GDB calls find_function_in_inferior ("malloc") when expression
evaluation needs to allocate memory in the inferior, e.g. for string
literal arguments.

The minimal-symbol fallback created a synthetic ordinary function
pointer from msymbol.value_address ().  If the symbol was a GNU IFUNC,
this discarded the IFUNC marker, so call_function_by_hand did not
resolve the symbol before calling it.

Use find_minsym_type_and_address to classify the minimal symbol and
propagate the GNU IFUNC marker to the synthetic function type.  This
keeps the existing fallback return type while allowing inferior calls
through IFUNC symbols to be resolved correctly.
---
 gdb/valops.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gdb/valops.c b/gdb/valops.c
index ab6fd5079e1..7d305871efc 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -133,11 +133,15 @@ find_function_in_inferior (const char *name, struct objfile **objf_p)
 	  struct gdbarch *gdbarch = objfile->arch ();
 
 	  struct type *type;
+	  struct type *resolved_type;
 	  CORE_ADDR maddr;
 	  type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
 	  type = lookup_function_type (type);
 	  type = lookup_pointer_type (type);
-	  maddr = msymbol.value_address ();
+	  resolved_type = find_minsym_type_and_address (msymbol.minsym, objfile,
+							&maddr);
+	  if (resolved_type->is_gnu_ifunc ())
+	    type->target_type ()->set_is_gnu_ifunc (true);
 
 	  if (objf_p)
 	    *objf_p = objfile;
-- 
2.43.0

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

[Andrew Burgess]

Muhammad Kamran <muhammad.kamran@arm.com> writes:

> GDB calls find_function_in_inferior ("malloc") when expression
> evaluation needs to allocate memory in the inferior, e.g. for string
> literal arguments.
>
> The minimal-symbol fallback created a synthetic ordinary function
> pointer from msymbol.value_address ().  If the symbol was a GNU IFUNC,
> this discarded the IFUNC marker, so call_function_by_hand did not
> resolve the symbol before calling it.
>
> Use find_minsym_type_and_address to classify the minimal symbol and
> propagate the GNU IFUNC marker to the synthetic function type.  This
> keeps the existing fallback return type while allowing inferior calls
> through IFUNC symbols to be resolved correctly.
> ---
>  gdb/valops.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Is it possible to create a test for this issue that would fail on other
targets?  There's gdb.base/gnu-ifunc.exp, from the patch I'm wondering
if all that would be needed is to place an ifunc function in a library,
and compile the library without debug information?  It's not super clear
from your description the exact steps that are needed to trigger this
bug.

>
> diff --git a/gdb/valops.c b/gdb/valops.c
> index ab6fd5079e1..7d305871efc 100644
> --- a/gdb/valops.c
> +++ b/gdb/valops.c
> @@ -133,11 +133,15 @@ find_function_in_inferior (const char *name, struct objfile **objf_p)
>  	  struct gdbarch *gdbarch = objfile->arch ();
>  
>  	  struct type *type;
> +	  struct type *resolved_type;
>  	  CORE_ADDR maddr;
>  	  type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
>  	  type = lookup_function_type (type);
>  	  type = lookup_pointer_type (type);
> -	  maddr = msymbol.value_address ();
> +	  resolved_type = find_minsym_type_and_address (msymbol.minsym, objfile,
> +							&maddr);
> +	  if (resolved_type->is_gnu_ifunc ())
> +	    type->target_type ()->set_is_gnu_ifunc (true);

There are other places in GDB where we use lookup_function_type, could
these also run into this issue?  It would be nice if the description
explained why other similar places in GDB don't need changing if that's
the case.

Thanks,
Andrew


>  
>  	  if (objf_p)
>  	    *objf_p = objfile;
> -- 
> 2.43.0

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

[Muhammad Kamran]

Hi Andrew,

Thanks for the review.

On 24/06/2026 16:53, Andrew Burgess wrote:
> Muhammad Kamran <muhammad.kamran@arm.com> writes:
> 
>> GDB calls find_function_in_inferior ("malloc") when expression
>> evaluation needs to allocate memory in the inferior, e.g. for string
>> literal arguments.
>>
>> The minimal-symbol fallback created a synthetic ordinary function
>> pointer from msymbol.value_address ().  If the symbol was a GNU IFUNC,
>> this discarded the IFUNC marker, so call_function_by_hand did not
>> resolve the symbol before calling it.
>>
>> Use find_minsym_type_and_address to classify the minimal symbol and
>> propagate the GNU IFUNC marker to the synthetic function type.  This
>> keeps the existing fallback return type while allowing inferior calls
>> through IFUNC symbols to be resolved correctly.
>> ---
>>   gdb/valops.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> Is it possible to create a test for this issue that would fail on other
> targets?  There's gdb.base/gnu-ifunc.exp, from the patch I'm wondering
> if all that would be needed is to place an ifunc function in a library,
> and compile the library without debug information?  It's not super clear
> from your description the exact steps that are needed to trigger this
> bug.

Yes, this can be tested.  I added a regression test in v2 to
gdb.base/gnu-ifunc.exp.  The test defines malloc as a GNU IFUNC in a
no-debug object, and links it with a small debug test program.  The test
then evaluates an inferior call with a string literal argument.  Copying
that string literal into the inferior forces GDB through
find_function_in_inferior ("malloc"), which exercises the minimal-symbol
fallback.

> 
>>
>> diff --git a/gdb/valops.c b/gdb/valops.c
>> index ab6fd5079e1..7d305871efc 100644
>> --- a/gdb/valops.c
>> +++ b/gdb/valops.c
>> @@ -133,11 +133,15 @@ find_function_in_inferior (const char *name, struct objfile **objf_p)
>>   	  struct gdbarch *gdbarch = objfile->arch ();
>>   
>>   	  struct type *type;
>> +	  struct type *resolved_type;
>>   	  CORE_ADDR maddr;
>>   	  type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
>>   	  type = lookup_function_type (type);
>>   	  type = lookup_pointer_type (type);
>> -	  maddr = msymbol.value_address ();
>> +	  resolved_type = find_minsym_type_and_address (msymbol.minsym, objfile,
>> +							&maddr);
>> +	  if (resolved_type->is_gnu_ifunc ())
>> +	    type->target_type ()->set_is_gnu_ifunc (true);
> 
> There are other places in GDB where we use lookup_function_type, could
> these also run into this issue?  It would be nice if the description
> explained why other similar places in GDB don't need changing if that's
> the case.

The issue is not lookup_function_type itself.  The bug fixed here is the
specific find_function_in_inferior minimal-symbol fallback: it had
already found a minimal symbol, but then built a synthetic callable
value without carrying over the symbol's STT_GNU_IFUNC classification.

I did not find another direct lookup_function_type caller with the same
minimal-symbol fallback pattern.  Some code does build ordinary function
pointer types for known non-IFUNC helper paths, so I have kept this
patch limited to the path needed by find_function_in_inferior.

Thanks,
Kamran

> 
> Thanks,
> Andrew
> 
> 
>>   
>>   	  if (objf_p)
>>   	    *objf_p = objfile;
>> -- 
>> 2.43.0
> 

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

[Carlos O'Donell]

On 6/24/26 5:50 AM, 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.
> 
> Should this be considered for backporting to release branches?

Yes please!

This blocks glibc 2.44 release with the current malloc IFUNCs.

It would be great to have this fixed in gdb 17.2.
  
> Muhammad Kamran (1):
>    gdb: Preserve IFUNC marker when finding inferior functions
> 
>   gdb/valops.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 


-- 
Cheers,
Carlos.

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

[Yury Khrustalev]

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.

Kind regards,
Yury

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

[Simon Marchi]

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.

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.

Simon

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

[Carlos O'Donell]

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.

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

[Simon Marchi]

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

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

[Carlos O'Donell]

On 6/25/26 7:52 PM, Simon Marchi wrote:
> 
> 
> 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".

When I started advertising this for glibc I worked with the downstream
distributions to adopt a "git pull --rebase" kind of model where they
would likewise just pull from the release branch and update.

This incentivizes the distributions to get involved, backport stable
fixes, and work collectively to help upstream maintain the release
branch and then update their own components.

In glibc we can see both Fedora and Debian actively backporting to
the release branch where the rule is "If it doesn't change ABI and
landed in master then you can backport it."

We have been doing this process for ~12 years:
https://inbox.sourceware.org/libc-alpha/542DBB6F.6040109@redhat.com/

-- 
Cheers,
Carlos.