From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC/RFA] Print in-memory struct return values Date: Tue, 11 May 2004 23:53:00 -0000 Message-id: <40A1675A.4010401@gnu.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> <200405091051.i49Ap6a2027479@elgar.kettenis.dyndns.org> X-SW-Source: 2004-05/msg00354.html 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. You can. %eax would start out as on the stack, and then later be marked as ``in register''. It's just the reverse flow of what happens to other registers. 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. Ah. This is what needs to be added to the return_value documentation. Andrew