From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: tolerate unavailable struct return values Date: Fri, 30 Nov 2001 13:33:00 -0000 Message-id: <20011130163218.A29232@nevyn.them.org> References: <20011129220913.2D72A5E9D8@zwingli.cygnus.com> <20011129173644.A15429@nevyn.them.org> X-SW-Source: 2001-11/msg00632.html 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25768 invoked by alias); 30 Nov 2001 21:33:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25371 invoked from network); 30 Nov 2001 21:31:51 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by hostedprojects.ges.redhat.com with SMTP; 30 Nov 2001 21:31:51 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 169vGc-0007p9-00; Fri, 30 Nov 2001 16:32:18 -0500 Date: Sat, 24 Nov 2001 10:23:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: tolerate unavailable struct return values Message-ID: <20011130163218.A29232@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20011129220913.2D72A5E9D8@zwingli.cygnus.com> <20011129173644.A15429@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00417.txt.bz2 Message-ID: <20011124102300.U2yMfaRSPuA-7wfQtEkQrh0f_4xxb0ivZJVCMNyUETY@z> 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer