This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Thanks,
Siva Chandra


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]