From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Daniel Jacobowitz Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: RFA: tolerate unavailable struct return values Date: Fri, 30 Nov 2001 13:51:00 -0000 Message-id: <3C07FF91.239D7794@cygnus.com> References: <20011129220913.2D72A5E9D8@zwingli.cygnus.com> <20011129173644.A15429@nevyn.them.org> <20011130163218.A29232@nevyn.them.org> X-SW-Source: 2001-11/msg00635.html 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8196 invoked by alias); 30 Nov 2001 21:51:33 -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 8106 invoked from network); 30 Nov 2001 21:51:22 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 30 Nov 2001 21:51:22 -0000 Received: from cygnus.com (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA20155; Fri, 30 Nov 2001 13:51:21 -0800 (PST) Message-ID: <3C07FF91.239D7794@cygnus.com> Date: Sat, 24 Nov 2001 23:01:00 -0000 From: Michael Snyder Organization: Red Hat X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00420.txt.bz2 Message-ID: <20011124230100.2XkLd-E4GqVQklyFwVpK7YWmYmGulET2JEC_uNL7RxA@z> 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.