[RFC] Struct return values

[RFC] Struct return values

[Mark Kettenis]

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

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.

Comments?

Mark

Re: [RFC] Struct return values

[Andrew Cagney]

> 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

Re: [RFC] Struct return values

[Mark Kettenis]

   Date: Fri, 09 Jan 2004 15:05:11 -0500
   From: 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

I guess I wasn't too familiar with SPARC at that moment.  For 32-bit
SPARC the return value address resides at %sp + 64 in the callers
stack frame, which valid until it's overwritten for a new function
call.  So yes, it is available 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.

Indeed, the old SPARC code looked at %o0, which is only guaranteed to
contain the address when the caller receives control again.  The
64-bit SPARC code still does this, and suffers from the same problems
as MIPS (although GCC seems to explicitly set %i0/%o0 to the return
value address upon return, something that the 64-bit SPARC ABI doesn't
seem to require).

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

Certainly.

   - 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

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.

   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.

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

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

Doesn't make sense to me too, but we're talking about unoptimized code
here.

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

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.

   --

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

I don't think so, at least not for 32-bit & 64-bit SPARC, IA-32 and
AMD64.

Mark

Re: [RFC] Struct return values

[Andrew Cagney]

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

Re: [RFC] Struct return values

[Andrew Cagney]

Mark, BTW,

How does:
	extract_returned_value_address (arch, type, caller_frame)
look for a function name?

Andrew

Re: [RFC] Struct return values

[Mark Kettenis]

   Date: Sat, 17 Jan 2004 14:08:45 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Mark, BTW,

   How does:
	   extract_returned_value_address (arch, type, caller_frame)
   look for a function name?

Seems fine to me.  I'll have a go at implementing this after I've
flushed some of my pending changes.  A target should only define this
method if it has a realiable way, at every point in a called function,
to fetch the address, isn't it?

Mark

Re: [RFC] Struct return values

[Andrew Cagney]

>    Date: Sat, 17 Jan 2004 14:08:45 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    Mark, BTW,
> 
>    How does:
> 	   extract_returned_value_address (arch, type, caller_frame)
>    look for a function name?
> 
> Seems fine to me.  I'll have a go at implementing this after I've
> flushed some of my pending changes.  A target should only define this
> method if it has a realiable way, at every point in a called function,
> to fetch the address, isn't it?

When looking at the code I found two cases:

"return VALUE":
GDB first pops the callers frame, and second stores the return VALUE. 
This means that the method will see caller's frame just after the callee 
has been forceably "returned".

"finish"
GDB first finishes the function, and second extracts the return VALUE. 
This again means that the method will see the caller's frame just after 
the callee has returned.

So perhaphs something like:
The target should only define this method if it has a reliable way of 
extracting the struct-convention return-value address using only 
information obtained from the caller's frame just after the callee has 
returned.  [insert something about how this is impossible on most ABIs :-)]

Andrew

Re: [RFC] Struct return values

[Mark Kettenis]

   Date: Sun, 18 Jan 2004 11:30:54 -0500
   From: Andrew Cagney <cagney@gnu.org>

   When looking at the code I found two cases:

   "return VALUE":
   GDB first pops the callers frame, and second stores the return VALUE. 
   This means that the method will see caller's frame just after the callee 
   has been forceably "returned".

   "finish"
   GDB first finishes the function, and second extracts the return VALUE. 
   This again means that the method will see the caller's frame just after 
   the callee has returned.

   So perhaphs something like:
   The target should only define this method if it has a reliable way of 
   extracting the struct-convention return-value address using only 
   information obtained from the caller's frame just after the callee has 
   returned.  [insert something about how this is impossible on most ABIs :-)]

Hmm, OK, but this means that there are really three classes of ABIs here:

a) The return value address is passed to the callee, and the callee
   may clobber the location where the address is stored (i.e. it's
   stored in the callee's stack frame, or in a scratch register).

b) The return value address is passed to the callee, and the callee
   may clobber the location where the address is stored (i.e. it's
   stored in the callee's stack frame, or in a scratch register).  We
   can't "return VALUE" or display the return value with "finish".

c) The return value address is passed to the callee in a location that
   isn't clobbered by the callee (i.e. in the caller's stack frame, or
   in a preserved register).

This means that

a) We cannot "return VALUE" or display the return value with "finish".

b) We cannot "return VALUE" but we can display the return values with
   "finish".

c) We can both "return VALUE" and display the return value with
   "finish".

Examples are:

a) The PPC System V psABI: The return value address is passed in r3,
   which is "volatile".

b) The AMD64 System V psABI: The return values address is passed in
   %rdi.  On return %rax will contain the address that has been passed
   in by the caller in %rdi.

c) The (32-bit) SPARC System V psABI: The return address is stored in
   a reserved slot in the caller's frame.

Personally I find it very usefull that GDB prints the return value
when I say "finish", so I'd like to make that work too.

Mark

Re: [RFC] Struct return values

[Andrew Cagney]

> Hmm, OK, but this means that there are really three classes of ABIs here:
> 
> a) The return value address is passed to the callee, and the callee
>    may clobber the location where the address is stored (i.e. it's
>    stored in the callee's stack frame, or in a scratch register).
> 
> b) The return value address is passed to the callee, and the callee
>    may clobber the location where the address is stored (i.e. it's
>    stored in the callee's stack frame, or in a scratch register).  We
>    can't "return VALUE" or display the return value with "finish".

(I suspect you ment something like: while the callee can clober the 
location containing the original return value address it is required to 
return that address in a known location when the function finishes)

> c) The return value address is passed to the callee in a location that
>    isn't clobbered by the callee (i.e. in the caller's stack frame, or
>    in a preserved register).
> 
> This means that
> 
> a) We cannot "return VALUE" or display the return value with "finish".
> 
> b) We cannot "return VALUE" but we can display the return values with
>    "finish".
> 
> c) We can both "return VALUE" and display the return value with
>    "finish".
> 
> Examples are:
> 
> a) The PPC System V psABI: The return value address is passed in r3,
>    which is "volatile".
> 
> b) The AMD64 System V psABI: The return values address is passed in
>    %rdi.  On return %rax will contain the address that has been passed
>    in by the caller in %rdi.
> 
> c) The (32-bit) SPARC System V psABI: The return address is stored in
>    a reserved slot in the caller's frame.

Can b) be made equivalent to c)?  Does the ABI require that the CFI 
unwind the %rax register such that it contains the return value address? 
  If that or something similar is true then it is just c).

> Personally I find it very usefull that GDB prints the return value
> when I say "finish", so I'd like to make that work too.

Yes, perhaps get SPARC working and then see what can be tinkered with 
for AMD.  It will eventually mean two methods, or an extra param.

Andrew

Re: [RFC] Struct return values

[Mark Kettenis]

   Date: Thu, 22 Jan 2004 09:20:46 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > Hmm, OK, but this means that there are really three classes of ABIs here:
   > 
   > a) The return value address is passed to the callee, and the callee
   >    may clobber the location where the address is stored (i.e. it's
   >    stored in the callee's stack frame, or in a scratch register).
   > 
   > b) The return value address is passed to the callee, and the callee
   >    may clobber the location where the address is stored (i.e. it's
   >    stored in the callee's stack frame, or in a scratch register).  We
   >    can't "return VALUE" or display the return value with "finish".

   (I suspect you ment something like: while the callee can clober the 
   location containing the original return value address it is required to 
   return that address in a known location when the function finishes)

Something like that, yes.  I must have inadvertedly replaced it with
the "can't return & finish" phrase :-(.  Sorry for the confusion.

   > c) The return value address is passed to the callee in a location that
   >    isn't clobbered by the callee (i.e. in the caller's stack frame, or
   >    in a preserved register).
   > 
   > This means that
   > 
   > a) We cannot "return VALUE" or display the return value with "finish".
   > 
   > b) We cannot "return VALUE" but we can display the return values with
   >    "finish".
   > 
   > c) We can both "return VALUE" and display the return value with
   >    "finish".
   > 
   > Examples are:
   > 
   > a) The PPC System V psABI: The return value address is passed in r3,
   >    which is "volatile".
   > 
   > b) The AMD64 System V psABI: The return values address is passed in
   >    %rdi.  On return %rax will contain the address that has been passed
   >    in by the caller in %rdi.
   > 
   > c) The (32-bit) SPARC System V psABI: The return address is stored in
   >    a reserved slot in the caller's frame.

   Can b) be made equivalent to c)?  Does the ABI require that the CFI 
   unwind the %rax register such that it contains the return value address? 
     If that or something similar is true then it is just c).

I'm afraid not.  Both %rdi and %rax aren't preserved across function
calls.  Therefore, I don't think it's reasonable to expect that the
CFI says something other than that its contents are undefined.

   > Personally I find it very usefull that GDB prints the return value
   > when I say "finish", so I'd like to make that work too.

   Yes, perhaps get SPARC working and then see what can be tinkered with 
   for AMD.  It will eventually mean two methods, or an extra param.

I'll do that.

Mark