Re: [PATCH v4] Make chained function calls in expressions work

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Siva Chandra wrote:
> On Tue, Nov 11, 2014 at 6:55 AM, Siva Chandra <sivachandra@google.com> wrote:
> > On Tue, Nov 4, 2014 at 7:40 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> >>> Shall I go with the thread route then?
> >>
> >> Yes, please.  Sorry for asking for extra work, but I think overall this
> >> will be the better implementation.
> >
> > I spent some time looking into how this can be done. While I do think
> > it can be done (and should be fairly straight forward), it seemed to
> > me that it would be more appropriate to cache the temporaries on the
> > "selected frame". WDYT?
> 
> Or, current frame?

Selected frame would be wrong (if the user selected a frame up the stack).

Current frame would be OK, I guess, but it doesn't seem straightforward
to do so.  Note that frame structs are transient and do not survive
running the inferior; once the inferior is restarted (even just for an
inferior call), all frame structs are freed and will be recreated once
the inferior stops again.  (That's why you use frame_id's and not just
struct frame pointers if you want to refer to a frame for longer.)
This makes struct frame mostly unsuitable to cache additional info.

The most cleanly "correct" solution would probably be to cache the temporaries
on the *dummy frame*, because that is the frame associated with all the
GDB-generated content on the stack, and the dummy_frame struct does persist
a bit longer than the frame struct.  However, getting there would still be
a bit more difficult, since we'd first have to arrange for a dummy frame to
persist over multiple inferior call invocations.  Currently, the dummy frame
is automatically popped in infrun as soon as the call returns.

If you want to have a look into that, that would certainly be fine with me,
but it is not a requirement.  Adding the info to the thread struct should
be straightforward and would be fine with me.

> > I promise I will not ask any more question after this; I will just
> > shut up and do whatever you prefer here.

No, please go ahead and ask questions; it's always better to hash the
main direction out before spending a lot of time on implementating
something ...  :-)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com