Re: [RFC] Struct return values

[Andrew Cagney <cagney@gnu.org>]

> Recently Andrew did some work on structure return values.  The result
> was that GDB now refuses to make a function return, that returns a
> struct accoriding to the "struct value" convention.  The reasoning
> behind this is that in general, we can't determine the address of the
> bit of memory where we're supposed to return the value if we're in the
> middle of such a function.

Yep,

- no one came up with an ABI that correctly preserved the 
struct-convention return value address such that it could be extracted 
at any time including just _after_ a function has returned

- all the existing ABI which implemented the old 
extract_struct_value_address did so erreneously vis:
> static CORE_ADDR
> mips_extract_struct_value_address (struct regcache *regcache)
> {
>   /* FIXME: This will only work at random.  The caller passes the
>      struct_return address in V0, but it is not preserved.  It may
>      still be there, or this may be a random value.  */
>   LONGEST val;
> 
>   regcache_cooked_read_signed (regcache, V0_REGNUM, &val);
>   return val;
> }
I believe that this is even true of that old SPARC code.

- the existing extract_struct_value_address, if it were to re-invent 
itself would needed an interface makeover (arch parameter?, frame 
parameter?).

- it only affected new architectures so, as you've done, the developer 
should notice and report that assumption no longer holds

 > 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

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.

- 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 :-/

> Furthermore, the testsuite contains the following comment:
> 
>                 # The struct return case.  Since any modification
>                 # would be by reference, and that can't happen, the
>                 # value should be unmodified and hence Z is expected.
>                 # Is this a reasonable assumption?
> 
> I think the answer to the question is "no".  It's perfectly allowed
> for the caller to provide a bit of scratch memory for the return
> value, and copy the contents of this bit of memory to the variable
> after the callee returns.  Now if we return from a random point in the
> callee, the contents of the scratch memory will be undetermined, and
> some random bytes will be copied into the variable.  This happens for
> code generated by the Sun compiler.  A way to fix this, is to make
> sure that GDB stops immediately after we return from the callee.  Is
> there an easy way to achieve this?  Otherwise, I think we should
> refrain from checking the value in this case.

I'm suprized that the compiler is generating a double copy, outch!

The test first does:
	return foo${n}
which leaves the inferior sitting in the caller at the return-to 
instuction (i.e., "GDB stops immediately after we return from the 
callee"), and the value sitting in registers or memory.  The test then does:
         -re "Make fun${n} return now.*y or n. $" {
             gdb_test_multiple "y" "${test}" {
                 -re "L${n} *= fun${n}.*${gdb_prompt} $" {
                     # Need to step off the function call
                     gdb_test "next" "L.* *= fun.*" "${test}"
                 }
                 -re "L[expr ${n} + 1] *= fun[expr ${n} + 
1].*${gdb_prompt} $" {
                     pass "${test}"
                 }
             }
         }
to force the return value into memory at its final destination.  Finally 
the test does the comparison you're seeing:
                 # The struct return case.  Since any modification
                 # would be by reference, and that can't happen, the
                 # value should be unmodified and hence Z is expected.
                 # Is this a reasonable assumption?

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

--

Since you're looking at this, is there still a need to pass the entire 
function signature and not just the function's return type to these 
methods?  The sh64 case appears to have evaporated :-(

Andrew