Re: [RFA] Generic solution for store_struct_address

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> 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. 
Example?  David Miller submitted patches that convert the SPARC to 
generic dummy frames.  I've deleted all the other register window 
architectures.

> > > * 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.
The obvious short-comming in the original patch was its relance on a 
global variable hack.  I didn't even consider it beyond that.

Since GDB only keeps complete track of the last inferior function call 
(using variables local to hand_call_function) I don't see any reason for 
even trying to add a stack.  (Especially a stack that is simply mimicing 
the behavour of the generic dummy frame stack.)

The above change will fix:

(gdb) print foo()
... print correct value ...
(gdb)

The above change won't fix:

(gdb) print foo ()
^C
.... 
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (catch_errors) will 
be abandoned.
(gdb) return value

Considering your patch.  The best it can do is, in the below:

(gdb) b foo
(gdb) run
break point in foo
(gdb) return value
``warning: ABI makes it impossible to find where to store the struct 
return value''
(gdb) print foo()
break point in foo
The program being debugged stopped while in a function called from GDB.
When the function (foo) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) return value
``warning: ABI makes it impossible to find where to store the struct 
return value''
(gdb)

Supress the second warning.  I think it is better to just keep the 
warning so that GDB's behavior is more consistent.

Andrew