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

[Siva Chandra <sivachandra at google dot com>]

On Wed, Oct 1, 2014 at 11:05 AM, Siva Chandra <sivachandra@google.com> wrote:
> 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.

A tangential point, GDB does not call destructors on these temporaries
which IMO is an error. That is why, in my 2/2, you will notice that
the expression's state is holding onto all the return value
temporaries in a vector instead of just the last one created; In a
future pass, I would like to implement invoking the destructors on
these temporaries after the expression result is evaluated.

Thanks,
Siva Chandra