Re: [patch] smart pointer support

["Ulrich Weigand" <uweigand@de.ibm.com>]

sami wagiaalla wrote:

> Hmm I see. I was under the impression that here the value is copied from 
> the inferior's return location to gdb memory. As the patch stands (with 
> the kfail) this can be removed, but I am actually looking for guidance 
> on how to ensure that this value is available for gdb to perform further 
> function calls that utilize it, especially when the return value is a 
> copy not a reference. As is described in this bug: 
> http://sourceware.org/bugzilla/show_bug.cgi?id=11606

So there's two issues here.  The first question is, what can you expect
from a GDB value representing the return value of an inferior function
call?  You will *always* get the value itself, as bytes copied to GDB's
memory.  In *some* cases, the value will in addition be of type lval_memory
meaning that the value is also present in inferior memory, *and you know
where*.  See existing code:

        switch (gdbarch_return_value (gdbarch, value_type (function),
                                      target_values_type, NULL, NULL, NULL))
          {
          case RETURN_VALUE_REGISTER_CONVENTION:
          case RETURN_VALUE_ABI_RETURNS_ADDRESS:
          case RETURN_VALUE_ABI_PRESERVES_ADDRESS:
            retval = allocate_value (values_type);
            gdbarch_return_value (gdbarch, value_type (function), values_type,
                                  retbuf, value_contents_raw (retval), NULL);
            break;
          case RETURN_VALUE_STRUCT_CONVENTION:
            retval = value_at (values_type, struct_addr);
            break;
          }

In the second case, we get a lval_memory value including the address
("struct_addr") where it resides.  In the first case, we just get a
non_lval value because the value doesn't reside in memory in the first
place; it was returned in registers.

Thinking more about this, the value_at case actually looks broken,
because while the value is in memory, that memory slot was just
temporarily allocated on the stack, and will go away as soon as
we return from call_function_by_hand!  So it might in fact be
better to just return a non_lval in that case, too ...


The second question is:  Well, if all we have is a non_lval, can we still
call a member function?  In priciple we could do the same what C++ does
and allocate a temporary copy on the stack; we'd probably want to this
at the time we call the member function in call_function_by_hand, similar
to how we already create temporary copies of call arguments as required.
That seems the way forward to fix the bug you point out ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com