From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16154 invoked by alias); 17 Dec 2001 23:09:30 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16109 invoked from network); 17 Dec 2001 23:09:26 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 17 Dec 2001 23:09:26 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id B21BF5E9D8; Mon, 17 Dec 2001 18:10:46 -0500 (EST) To: Elena Zannoni Cc: Michael Snyder , Daniel Jacobowitz , Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: RFA: tolerate unavailable struct return values References: <20011129220913.2D72A5E9D8@zwingli.cygnus.com> <20011129173644.A15429@nevyn.them.org> <20011130163218.A29232@nevyn.them.org> <3C07FF91.239D7794@cygnus.com> <15383.42118.203889.389960@localhost.localdomain> From: Jim Blandy Date: Mon, 17 Dec 2001 15:09:00 -0000 In-Reply-To: Elena Zannoni's message of Wed, 12 Dec 2001 13:40:06 -0500 Message-ID: X-Mailer: Gnus v5.3/Emacs 19.34 X-SW-Source: 2001-12/txt/msg00434.txt.bz2 Elena Zannoni writes: > Michael Snyder writes: > > Daniel Jacobowitz wrote: > > > On Fri, Nov 30, 2001 at 03:49:52PM -0500, Jim Blandy wrote: > > > > Daniel Jacobowitz writes: > > > > > On Thu, Nov 29, 2001 at 05:09:13PM -0500, Jim Blandy wrote: > > > > > > > > > > > > On some architectures, it's impossible for GDB to find structs > > > > > > returned by value. These shouldn't be failures. Should they be > > > > > > passes? > > > > > > > > > > Out of curiousity, which architectures? And to be pedantic, I suspect > > > > > that it might be "not always possible" rather than actually > > > > > impossible. > > > > > > > > The one I have in mind is the S/390, although I'm pretty sure there > > > > are others. I've included the bug report I sent to the S/390 GCC > > > > maintainers below. > > > > > > > > One approach would be to hope that the return buffer's address was > > > > still there in the register it was passed in. But there's no way to > > > > tell when you're wrong. GDB will just print garbage, and the user > > > > will think their program is wrong. Better to simply say, "I can't > > > > find this information reliably", and let the user, who knows their > > > > program, find another way to get the info --- setting a breakpoint on > > > > the return statement, or looking at where the caller put the > > > > structure. > > > > > > Hmmmm. I wonder if MIPS could ever be affected by this? I don't think > > > the MIPS ABI specifies that $a0 remains live. It looks as if the value > > > of $a0 is always returned in $v0 in such functions, though. > > > > It's not an uncommon problem, and I imagine we get it wrong a lot of the time. > > Have you looked at the macro VALUE_RETURNED_FROM_STACK ? I defined that > long time ago for hppa. It looks like the rs6000-tdep.c tries to deal > with the same problem as well. > > Maybe we should clean up that code, which came in as part of the HP > merge :-(. Looking at the following code in infcmd.c: /* We cannot determine the contents of the structure because it is on the stack, and we don't know where, since we did not initiate the call, as opposed to the call_function_by_hand case */ #ifdef VALUE_RETURNED_FROM_STACK value = 0; #ifdef UI_OUT ui_out_text (uiout, "Value returned has type: "); ui_out_field_string (uiout, "return-type", TYPE_NAME (value_type)); ui_out_text (uiout, "."); ui_out_text (uiout, " Cannot determine contents\n"); #else /* UI_OUT */ printf_filtered ("Value returned has type: %s.", TYPE_NAME (value_type)); printf_filtered (" Cannot determine contents\n"); #endif /* UI_OUT */ #else value = value_being_returned (value_type, stop_registers, structure_return); and then at the following code in valops.c: #ifdef VALUE_RETURNED_FROM_STACK if (struct_return) return (value_ptr) VALUE_RETURNED_FROM_STACK (value_type, struct_addr); #endif the stuff in infcmd.c looks backwards to me. Wasn't the intention to fall back to printing the type when VALUE_RETURNED_FROM_STACK is *not* defined? TYPE_NAME is just the structure tag; don't we want to print the `struct' or `union' there? The `type_print' function takes care of that. Frankly, I don't even think it's that useful to print the type. The user knows what function was called, and can use `ptype' or `whatis' if they want to know the type.