Re: [RFA] Generic solution for store_struct_address

[Michael Snyder <msnyder@redhat.com>]

Andrew Cagney wrote:
> 
> > Andrew Cagney wrote:
> >
> >>
> >
> >> > On Aug 21,  7:22pm, Michael Snyder wrote:
> >> >
> >> >
> >
> >> >> Kevin, would you by any chance be in a position to test it on ia64
> >> >> and/or
> >> >> rs6000?
> >
> >> >
> >> >
> >> > Sure, I'll give it a spin...
> >
> >>
> >> Just FYI, given the thread:
> >> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00674.html
> >> I'm assuming that this patch is dropped.
> >
> >
> > Why?  I didn't drop it.  You commented that using generic dummy
> > frames was a better solution, but it remains true that some
> > targets do not use generic dummy frames, and I'm not sure that
> > all targets can use them.
> 
> You mean:
> 
> >> Adding such a field to the generic dummy frame is a good idea --
> >> but some architectures don't use the generic dummy frames.
> 
> > That can be fixed by converting the architecture to generic dummy frames :-)
> 
> That is a side issue --- anyone fixing a problem need only get it
> working with targets using generic dummy frames.  Any other target
> should first be converted to generic dummy frames anyway.

That may or may not be possible. 

> Anyway, summarizing posts such as:
> 
> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00688.html
> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00705.html
> 
> > As far as I know, there are two cases:
> >
> > 1. a normal function forced to return:
> > (gdb) break foo
> > (gdb) finish
> 
> Your patch does not, and cannot fix this case.

I know that.  It does fix case 2, and that's an improvement.


> > 2. an inferior function call:
> > (gdb) print foo()
> 
> Your patch fixes this case.  However, it is far easier to replace the
> infrun.c code block:
> 
> > * Figure out the value returned by the function. */
> > /* elz: I defined this new macro for the hppa architecture only.
> > this gives us a way to get the value returned by the function from the stack,
> > at the same address we told the function to put it.
> > We cannot assume on the pa that r28 still contains the address of the returned
> > structure. Usually this will be overwritten by the callee.
> > I don't know about other architectures, so I defined this macro
> > */
> >
> > #ifdef VALUE_RETURNED_FROM_STACK
> > if (struct_return)
> > {
> > do_cleanups (retbuf_cleanup);
> > return VALUE_RETURNED_FROM_STACK (value_type, struct_addr);
> > }
> > #endif
> 
> With the corresponding code lifted from HP/UX.

Andrew, this approach has the same short-coming as the approach
that you rejected when I tried to use it last week.  It has no
stack.  It will not handle nested target function calls, because
this part of gdb is not recursive.  The patch that I am submitting
here does not have that problem -- it keeps nested return addresses
in a stack.