Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>
To: Andrew Burgess <aburgess@redhat.com>,
	Keith Seitz <keiths@redhat.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Tom Tromey <tom@tromey.com>
Subject: RE: [PATCH v4] infcall: Add support for integer literals as reference function paramters
Date: Mon, 2 Feb 2026 17:05:40 +0000	[thread overview]
Message-ID: <DM4PR11MB73036958FAF57FECDFE302ADC49AA@DM4PR11MB7303.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87h5s5g7vt.fsf@redhat.com>

On Wednesday, January 28, 2026 2:55 PM, Andrew Burgess wrote:
> Keith Seitz <keiths@redhat.com> writes:
> 
> > This patch attempts to mitigate the shortcomings of passing literals
> > to inferior function calls requiring references.  The specific use
> case here
> > is std::map's operator[]:
> >
> > std::map int_map<int, int>;
> > int_map[1] = 10;
> > (gdb) print int_map[1]
> > Attempt to take address of value not located in memory.
> >
> > This is occurring because while value_coerce_to_target understands
> > that some values need to be allocated and copied to the inferior's
> > memory, it only considers the actual parsed type of the argument
> value,
> > ignoring the actual type of the function parameter. That is,
> > in this specific case, the value's parsed type is TYPE_CODE_INT, but
> > the function requires TYPE_CODE_REF. We need to account for the
> > reference.
> >
> > In value_arg_coerce, we have special handling for references, but it
> > has not specifically dealt with this case. It now checks if the
> > reference is in memory, and if it isn't, it copies it, if the type
> > is trivially copyable.
> >
> > As a result of this patch, the last remaining failure in c++/15372 is
> now
> > fixed, and that bug can be closed.
> >
> > With this patch, we can now print map entries with integer keys:
> >
> > (gdb) print int_map[1]
> > $1 = (std::map<int, int, std::less<int>, std::allocator<std::pair<int
> const, int> > >::mapped_type &) @0x41f2d4: 10
> >
> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15372
> > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25957
> >
> > Changes in v4
> > - Allocate to stack instead of heap
> 
> I'm interested by this change.  Within value_arg_coerce, a few lines
> before your change, there's this comment:
> 
>   /* Force the value to the target if we will need its address.  At
>      this point, we could allocate arguments on the stack instead of
>      calling malloc if we knew that their addresses would not be
>      saved by the called function.  */
>   arg = value_coerce_to_target (arg);
> 
> I don't believe there's anything stopping the inferior function taking
> the address of the reference argument and storing it.  Could you explain
> this change a little more?

My review comment must have caused this change in v4.  I'm sorry about that.

GDB allocates implicit pass-by-reference arguments on stack.  It also allocates
struct return values on stack [1].  That is the reason why I had commented so.

Suppose I have a struct S and in the code there is

  S *gp;

  void func (S &s1) { gp = &s1; }

  S bar () { return {99}; }

Then, in GDB if I do

  (gdb) print func(bar())

the global pointer `gp` would be pointing to a stack-allocated object,
which is now garbage.  I believe we should fix this then, right?
(It's a side topic and not directly part of Keith's patch.)

Regards,
-Baris

[1] infcall.c:

  /* Reserve space for the return structure to be written on the
     stack, if necessary.

     While evaluating expressions, we reserve space on the stack for
     return values of class type even if the language ABI and the target
     ABI do not require that the return value be passed as a hidden first
     argument.  This is because we want to store the return value as an
     on-stack temporary while the expression is being evaluated.  This
     enables us to have chained function calls in expressions.

     Keeping the return values as on-stack temporaries while the expression
     is being evaluated is OK because the thread is stopped until the
     expression is completely evaluated.  */

  if (return_method != return_method_normal
      || (stack_temporaries && class_or_union_p (values_type)))
    struct_addr = reserve_stack_space (values_type, sp);


Intel Deutschland GmbH
Registered Address: Dornacher Straße 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht München HRB 186928

  reply	other threads:[~2026-02-02 17:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-16 15:48 [PATCH] " Keith Seitz
2025-10-17 14:49 ` Tom Tromey
2025-10-20 19:00   ` Keith Seitz
2025-10-20 19:36 ` [PATCH v2] " Keith Seitz
2025-10-21 20:19   ` Tom Tromey
2025-10-22 12:05     ` Andrew Burgess
2025-10-22 13:21       ` Tom Tromey
2026-01-22 19:05       ` Keith Seitz
2026-01-23 14:07         ` Aktemur, Tankut Baris
2026-01-27 18:43           ` Keith Seitz
2026-01-27 19:01 ` [PATCH v4] " Keith Seitz
2026-01-28  8:24   ` Aktemur, Tankut Baris
2026-01-28 13:54   ` Andrew Burgess
2026-02-02 17:05     ` Aktemur, Tankut Baris [this message]
2026-02-02 17:21     ` Keith Seitz
2026-01-30 20:59   ` Tom Tromey
2026-02-02 16:58     ` Keith Seitz
2026-02-02 17:22       ` Aktemur, Tankut Baris
2026-02-12 16:31       ` Tom Tromey
2026-03-12 14:14 ` [PATCH v5] infcall: Add support for integer literals as reference function parameters Keith Seitz
2026-03-12 16:23   ` Tom de Vries
2026-03-12 16:45     ` Keith Seitz
2026-03-12 17:12 ` [PATCH v6] " Keith Seitz
2026-03-17 14:10   ` Andrew Burgess
2026-03-17 18:11     ` Keith Seitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM4PR11MB73036958FAF57FECDFE302ADC49AA@DM4PR11MB7303.namprd11.prod.outlook.com \
    --to=tankut.baris.aktemur@intel.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=keiths@redhat.com \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox