Re: [RFA] Generic solution for store_struct_address

[Andrew Cagney <ac131313@ges.redhat.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