Re: GDB and C++: handling of POD/non-POD objects

[Daniel Jacobowitz <drow@false.org>]

On Tue, Jun 28, 2005 at 12:48:44PM +0200, Christophe LYON wrote:
> 
> > > Here's a patch; I haven't updated or tested it in a while.  I need to
> > > rework it, and I need to check a couple of existing disabled tests that
> > > it probably affects; I just haven't had the time yet.
> > >
> 
> I have managed to include your patch in our gdb-6.1 source tree.
> 
> However, I had to remove parts of the infcall.c patch, namely:
> +  if (cp_struct_return)
> +    {
> +      struct value **new_args;
> +
> +      /* Add the new argument to the front of the argument list.  */
> +      new_args = xmalloc (sizeof (struct value *) * (nargs + 1));
> +      new_args[0] = value_from_pointer (lookup_pointer_type
> (value_type),
> +                                       struct_addr);
> +      memcpy (&new_args[1], &args[0], sizeof (struct value *) * nargs);
> +      args = new_args;
> +      nargs++;
> +      args_cleanup = make_cleanup (xfree, args);
> +    }
> +  else
> +    args_cleanup = make_cleanup (null_cleanup, NULL);
> 
> (along with the declaration and cleanup of args_cleanup)
> 
> Indeed, for our target, the pointer to the memory area reserved
> to hold the return value is passed as a hidden pointer, before
> 'this', but it does not make all the parameters shift.
> 
> From what I found in the C++ abi, 3.1.4, the return value is
> passed in an implicit hidden pointer, so I guess we are right,
> and the code above is incorrect.

What target and compiler is this?  This is contrary to the normal
interpretation of the ABI.  3.1.4 specifies that it is "an implicit
first parameter", which does imply a parameter shift.

This makes a substantial difference on ia64; this goes in the first
parameter register, instead of in the normal C structure return
register.

-- 
Daniel Jacobowitz
CodeSourcery, LLC