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

Siva Chandra sivachandra@google.com
Thu Oct 9 00:02:00 GMT 2014


On Tue, Sep 30, 2014 at 5:42 PM, Siva Chandra <sivachandra@google.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.
>>
>> Patch 1/2 - Adds new lval_type named lval_mirrored_on_inferior_stack.
>> Also adds support for values with this lval_type.
>> Patch 2/2 - Enables chained function calls by mirroring values
>> returned by inferior functions in the inferior stack.
>>
>> Patch 2/2 only targets values returned by call_function_by_hand. I
>> think similar things can done for call_internal_function and
>> call_xmethod. I will extend the idea to these functions as well after
>> this patch series is approved (if at all).
>
> I used global state in patch 2/2. I thought eliminating that would not
> be a straightforward task. However, I spent time looking into it and
> it turned out to be much simpler than I had anticipated. I have now
> updated both 1/2 and 2/2 to not use any global state. I have also
> regression tested and found that a known failure now passes. Will
> follow up with v2 of 1/2 and 2/2 both.

Ping. Links to the other patches in this series:

https://sourceware.org/ml/gdb-patches/2014-10/msg00001.html
https://sourceware.org/ml/gdb-patches/2014-10/msg00002.html



More information about the Gdb-patches mailing list