> 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.
- 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.