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

[Siva Chandra <sivachandra at google dot com>]

On Wed, Oct 1, 2014 at 6:15 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
>> On Fri, Sep 26, 2014 at 6:29 AM, Siva Chandra <sivachandra@google.com> wrote:
>> > This patch series enables having chained function calls in
>> > expressions. An example of a chained function call is shown in PR
>> > c++/11606. It has an example of a chain of two function calls. This
>> > patch series enables chains of any number of function calls.
>> >
>> > Currently, an inferior function call is handled via
>> > call_function_by_hand. The value returned by the inferior function is
>> > copied into a GDB value whose lval_type is not_lval. Its contents are
>> > stored within the value irrespective of whether the return value is in
>> > inferior memory or in a register. Consequently, any subsequent
>> > function call in the expression which requires this value's address as
>> > an argument throws an error as the value is not in inferior memory.
>> >
>> > This patch series keeps most of the current flow intact, except that
>> > the value returned by the inferior function is made to be a new
>> > lval_type called lval_mirrored_on_inferior_stack. These values have a
>> > mirrored value of lval_type lval_memory which reside on the inferior
>> > stack. They reside on the stack only for the duration for which the
>> > expression is evaluated. This enables value_address to return the
>> > address of the stack mirror instead of throwing an error.
>
> I'm wondering if there isn't a simpler way to solve this issue: couldn't
> you instead during preparation of the second call_function_by_hand simply
> allocate extra space on the stack and copy not_lval values whose address
> needs to be taken there?   This would avoid adding the new lval type, all
> the extra state to track mirrored values during an expression, and would
> actually allow you to pass *other* not_lval values to inferior calls too
> (not just those originating from another inferior call).

I did think about this route. However, look at the comment at
eval.c:1405. It has an argument for why we should not in general copy
function args on to the stack.

My patches here target return values of functions. Though return
values end up being function arguments in a chained function call
expression, IMO return values do not suffer from the same problem
pointed to in the comment from above.

1. If a function returns a reference, creating a copy of the reference
on the stack and passing it around for the duration the expression is
being evaluated should not be a problem.
2. If a function returns a value, then it is either returned on the
stack or in a register. My patches do not really disturb the case of a
value being returned on stack. Even when values are returned in
registers, intermediate return values are only temporaries and holding
onto their addresses in some stateful entity will be an error.

Thanks,
Siva Chandra