This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Generic solution for store_struct_address
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.