From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27108 invoked by alias); 9 Sep 2003 17:35:48 -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 27096 invoked from network); 9 Sep 2003 17:35:46 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 9 Sep 2003 17:35:46 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19wmP2-0001gW-2r; Tue, 09 Sep 2003 13:35:44 -0400 Date: Tue, 09 Sep 2003 17:35:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/6.0] Better handle unspecified CFI values Message-ID: <20030909173543.GA5722@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <3F593115.4030407@redhat.com> <20030906213351.GA1101@nevyn.them.org> <3F5D1AE7.7020306@redhat.com> <20030909033053.GA8904@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00163.txt.bz2 On Tue, Sep 09, 2003 at 12:23:27PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > Yes - normally. On S/390, stdcall, et cetera (anywhere where the hack > > would be wrong) it gets even worse. We can only compute expressions > > describing a memory location where the register is saved, not computed > > values. For stack pointers (and maybe frame pointers on some > > architectures?) this isn't good enough. > > Not to pursue unimportant tangents, but why would the hack be wrong on > the S/390? Its frames are normally FP-free, but aside from that, > what's unusual about it? I'm wrong about the S/390 being the problem - in fact it was the _opposite_ of the problem. From: http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00904.html From the previous discussions, it would appear to me that the real difference between s390 and other platforms here is that on s390, the stack pointer register is saved and restored from the call stack frame, like any other call- saved register. This means that uw_install_context can install the target stack pointer simply by writing it into the current stack frame, just like any other call- saved register. If this is possible, there is no need for the unwinder routines to perform any special handling w.r.t. the stack pointer register at all. This means that there should be no need to define EH_RETURN_STACKADJ_RTX, and everything related to this should be omitted by the library. This also means that the special-cased code for 'simulating' the stack pointer register in uw_update_context (which is what caused the breakage on s390) is just superfluous. GCC has a local hack in it, essentially, which handles adjusting the stack pointer for a frame back far enough. At least it seems that way to me. This hack is equivalent to the problem that GDB has for figuring out the saved SP. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer