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

Siva Chandra
2014-10-15T13:43:10Z

On Wed, Oct 8, 2014 at 5:02 PM, Siva Chandra <sivachandra@google.com> wrote:
> 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

Ping.