Re: [PATCH 0/2] Make chained function calls in expressions work

[Siva Chandra <sivachandra@google.com>]

I agree with everything you have said and listed. I have one last point to make.

On Wed, Oct 22, 2014 at 9:59 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> - Do something along the lines of your patch (with the changes already
>   discussed) to preserve return value temporaries as lval_memory objects
>   in those cases where they are mandated by the ABI (i.e. for types that
>   have a non-trivial copy constructor or destructor).

Restricting to just those values whose address is returned in a hidden
param (per ABI) is OK, but an implementation detail made me to include
all types of return values. There are two times when a return value's
address is required:

1. When a method is invoked on the return value: GDB has to evaluate
the 'this' pointer. This is done in eval.c.
2. When the return value is in turn passed as a parameter to a
function expecting a reference: GDB has to evaluate the address of the
value and generate a TYPE_CODE_REF value from it. This logic is in
'value_arg_coerce' in infcall.c.

For objects returned in registers, having logic to create a copy on
the stack for situations like 2 is fine. However, for situations like
1, I do not think there is any way to tell whether one is dealing with
an intermediate return value or not. In which case, we are hit by the
comment at eval.c:1405. This is the reason why I have return values
returned in registers copied on to the stack in my patch. Note that,
doing a bit copy of objects returned in registers should be just fine
as they do not have non-trivial copy constructors or destructors (if
they do, then ABI says that they wont be returned in registers).

One way to get around the comment at eval.c:1405 is to make copies of
only those objects which are not_lval and which do not have
non-trivial copy-ctors or d-tors. The same thing has be to done for 2
anyway if we take this route, meaning that we change the flow in two
places (infcall.c and eval.c). If you feel that this is OK, I will
take this route. My intention was to keep the existing logic as is for
as much as possible. If we keep what I have in my patch, then we only
need to change 'value_arg_coerce' in infrun.c (and that too, only to
enable passing non-lvalue parameters to functions expecting
const-reference arguments).