Re: [PATCH/RFC/RFA] Print in-memory struct return values

[Mark Kettenis <kettenis@chello.nl>]

   Date: Sat, 08 May 2004 20:07:55 -0400
   From: Andrew Cagney <cagney@gnu.org>

   >    Date: Sat, 08 May 2004 17:12:21 -0400
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    > Ouch.  That's really ugly.  I thought RETURN_VALUE_STRUCT_CONVENTION
   >    > was already long enough.  I'd really like to avoid thos really long
   >    > names.  Hmm what if I use:
   >    > 
   >    > RETURN_VALUE_ABI_RETURNS_ADDRESS
   >    > RETURN_VALUE_ABI_PRESERVES_ADDRESS
   > 
   >    yes.
   > 
   > So I checked in the attached.  The patches also corners
   > RETURN_VALUE_ABI_PRESERVES_ADDRESS, but doesn't implement it yet.
   > I'll do that when I touch SPARC again.
   > 
   > The patch induces some PASS->KFAIL changes in the testsuite.  This is
   > actually a problem with the testsuite.  The tests in question assume
   > that if "finish" prints a return value, "return" should work.
   > RETURN_VALUE_ABI_RETURNS_ADDRESS makes this assumption invalid.  We
   > should probably just remove those tests, but perhaps we can do
   > something smarter.

   How come it doesn't work?

   Popping the caller's frame should (assuming the unwind info is correct) 
   restore the struct-return address register to the value that the callee 
   expects.  return_value can then use that register value to find the 
   location at which to store the struct?

The problem is in the "assuming the unwind info is correct".  It's not
there.  It will probably never be there.  This isn't a normal register
save/restore.  The incoming address will be on the stack.  The callee
moves it into %eax somewhere, but we don't know where and when.  You
simply can't express this in DWARF2 CFI.

Now, we could do some nifty prologue/epilogue analysis and make a good
guess at where the address is stored.  Compilers seem to either do the
move in the prologue (as the SVR4 ABI suggests, see
i386_analyze_struct_return()) or leave the address on the stack until
the epilogue (as GCC does).  However, we can never be sure.  This
would lead to the unreliabilities you were trying to get rid of when
gdbarch_return_value() was instroduced.