From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32698 invoked by alias); 18 Dec 2001 17:35:13 -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 32653 invoked from network); 18 Dec 2001 17:35:11 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 18 Dec 2001 17:35:11 -0000 Received: from rtl.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id JAA06308; Tue, 18 Dec 2001 09:34:28 -0800 (PST) Received: (from ezannoni@localhost) by rtl.cygnus.com (8.11.2/8.11.0) id fBIEvOr01697; Tue, 18 Dec 2001 09:57:24 -0500 X-Authentication-Warning: localhost.localdomain: ezannoni set sender to ezannoni@cygnus.com using -f From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15391.22867.927756.592686@localhost.localdomain> Date: Tue, 18 Dec 2001 09:35:00 -0000 To: Jim Blandy Cc: Elena Zannoni , Michael Snyder , Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: RFA: tolerate unavailable struct return values In-Reply-To: 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> X-Mailer: VM 7.00 under Emacs 20.7.1 X-SW-Source: 2001-12/txt/msg00442.txt.bz2 Jim Blandy writes: > > 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? Not all the times, no, it was meant to be only used by hpux. I didn't have any way to test other targets when I wrote that, so I didn't want to touch anything else (whether or not such other targets could display the structre correctly). It should definitely be cleaned up. > > 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. > Probably. > 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. I wanted it to be more informative, and remind the user of what the result would have been, w/o them having to do an extra step. Elena