Re: [RFC] Struct return values

[Andrew Cagney <cagney@gnu.org>]

>     > However, it turns out that with 32-bit
>     > SPARC, we can find out.  The SPARC stack frames have a reserved slot
>     > for this address.  Should we allow returning in this case?
> 
>    If it's possible to do it robustly ...
> 
>    Is that reserved slot still defined after the return instruction has 
>    been executed but before the breakpoint has been hit?  Consider the 
>    sequence:
> 	   return
> 	   <signal>
> 	   breakpoint at return address
> 
> Yes, the signal handler might touch the register save area at %sp + 0,
> but should leave alone the return value address at %sp + 64, and
> everything above that address.

(sparc stack grows downwards) Ah, what a bizare ABI.

>    I know of two cases:
> 
>    - print_return_value with a tweak round
>       /* FIXME: 2003-09-27: When returning from a nested inferior function
> 	 call, it's possible (with no help from the architecture vector)
> 	 to locate and return/print a "struct return" value.  This is just
> 	 a more complicated case of what is already being done in in the
> 	 inferior function call code.  In fact, when inferior function
> 	 calls are made async, this will likely be made the norm.  */
>       else if (gdbarch_return_value_p (current_gdbarch))
>    The function has already returned so the method would need to take the 
>    callee's frame and return the return value's address.
> 
> I'm not sure I follow you here, but since the return value address
> lives at %sp + 64 in the caller's frame, I don't expect any problems.

Tipo, caller, not callee.

>    - return_command where the function hasn't yet returned (both the caller 
>    and callee frame would be available).  Previously this case never worked 
>    (I fixed the small structs case)!  It would be possible to use call the 
>    same method as for print_return_value (passing the caller's frame).
> 
>    Which ever, the doco will need to be really clear that ABI's typically 
>    make this impossible :-/
> 
> Yes indeed, the 32-bit SPARC ABI is the only case I know of where this
> stuff is possible.
> 
>    Note that the test needs to ensure that the code storing the return 
>    value in memory is executed.  That way the test checks for consistency 
>    between GDB and the compiler, and not GDB and GDB.
> 
>    What you could look at is:
> 	    -re ".*${gdb_prompt} $" {
> 		if $return_value_unimplemented {
> 		    # What a suprize.  The architecture hasn't implemented
> 		    # return_value, and hence has to fail.
> 		    kfail "$test" gdb/1444
> 		} else {
> 		    fail "$test"
> 		}
> 	    }
>    and soften that test a little (however, if the sparc should work in all 
>    cases even that tweak won't be needed).
> 
> OK, but I think the SPARC case has shown that a compiler can simply
> generate stupid code that invalidates the assumptions made by the
> testsuites on other platforms too.

I'd rather see this made conditional on the compiler.  I think the 
current cross check between "finish" and "return" is very important to 
that test (its one of the reasons why the new test is flushing out so 
many bugs).  Hmm, but then, by fixing the SPARC's struct return case for 
"return" and "finish", won't the immediate need for this check have been 
eliminated?  For the 32-bit SPARC, that test path should never be reached?

Hmm, also, should the final cross check be tweaked, so that for the 
32-bit SPARC any unknown value is a failure?

enjoy,
Andrew