From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: cagney@gnu.org Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC/RFA] Print in-memory struct return values Date: Sun, 09 May 2004 14:03:00 -0000 Message-id: <200405091051.i49Ap6a2027479@elgar.kettenis.dyndns.org> References: <200405071707.i47H7kG5071172@elgar.kettenis.dyndns.org> <409C0F30.4090409@gnu.org> <200405081958.i48JwlUU000353@elgar.kettenis.dyndns.org> <409D4216.4050401@gnu.org> <200405082101.i48L1NUK000503@elgar.kettenis.dyndns.org> <409D4D35.2090803@gnu.org> <200405082302.i48N2Jif026166@elgar.kettenis.dyndns.org> <409D765B.2030209@gnu.org> X-SW-Source: 2004-05/msg00269.html Date: Sat, 08 May 2004 20:07:55 -0400 From: Andrew Cagney > Date: Sat, 08 May 2004 17:12:21 -0400 > From: Andrew Cagney > > > 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.