From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27099 invoked by alias); 12 Dec 2001 19:27:21 -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 26959 invoked from network); 12 Dec 2001 19:27:15 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 12 Dec 2001 19:27:15 -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 LAA04289; Wed, 12 Dec 2001 11:27:10 -0800 (PST) Received: (from ezannoni@localhost) by rtl.cygnus.com (8.11.2/8.11.0) id fBCIe6f01640; Wed, 12 Dec 2001 13:40:06 -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: <15383.42118.203889.389960@localhost.localdomain> Date: Wed, 12 Dec 2001 11:27:00 -0000 To: Michael Snyder Cc: Daniel Jacobowitz , Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: RFA: tolerate unavailable struct return values In-Reply-To: <3C07FF91.239D7794@cygnus.com> References: <20011129220913.2D72A5E9D8@zwingli.cygnus.com> <20011129173644.A15429@nevyn.them.org> <20011130163218.A29232@nevyn.them.org> <3C07FF91.239D7794@cygnus.com> X-Mailer: VM 7.00 under Emacs 20.7.1 X-SW-Source: 2001-12/txt/msg00325.txt.bz2 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 :-(. Elena