From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 368 invoked by alias); 3 Apr 2005 21:41:33 -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 302 invoked from network); 3 Apr 2005 21:41:27 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 3 Apr 2005 21:41:27 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DICqU-0005RK-Pe; Sun, 03 Apr 2005 17:41:26 -0400 Date: Sun, 03 Apr 2005 21:41:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Teach dwarf2-frame.c about StackGhost Message-ID: <20050403214126.GB20654@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <200504022218.j32MIgoQ032738@elgar.sibelius.xs4all.nl> <20050403003443.GA23039@nevyn.them.org> <200504031903.j33J3VC8017984@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504031903.j33J3VC8017984@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00038.txt.bz2 On Sun, Apr 03, 2005 at 09:03:31PM +0200, Mark Kettenis wrote: > Date: Sat, 2 Apr 2005 19:34:43 -0500 > From: Daniel Jacobowitz > > On Sun, Apr 03, 2005 at 12:18:42AM +0200, Mark Kettenis wrote: > > One of the things that still keeps me from enabling the DWARF2 > > unwinder on SPARC is the fact that it doesn't play nice with > > StackGhost. Here is an attempt to make dwarf2-frame.c deal with it by > > introducing yet another register rule. People might object since this > > is only sort of architecture independent code. However it seems that > > this is the cleanest way to solve this. > > Ewww... this isn't even vaguely architecture independent code. It > seems like it's in the wrong place; there's no reason StackGhost > must be restricted to register windows. > > On the contrary. The whole idea pretty much depends on the concept of > register windows. Now the number of register window architectures is > fairly limited: SPARC, UltraSPARC and IA-64. I have just gone and looked up the details of StackGhost. Obviously, I misunderstood it. Similar mechanisms are possible elsewhere, but not this one. > Here's an alternative that I think is cleaner (and will work... I > hope): create a sparc-specific unwinder. Its sniffer can call the > dwarf2 sniffer; similarly for this_id and prev_register. Then you can > handle the StackGhost cookie when you are requested to unwind the PC. > > The problem here is that whether you need to apply the stackghost > cookie is highly dependent on where exactly %i7 is stored. If it is > stored in the reserved stack slot then you need to apply the cookie, > otherwise you won't. The way you suggests makes it hard to get at > that information. I think it would still be fairly straightforward - but if you don't, then I withdraw my objection. -- Daniel Jacobowitz CodeSourcery, LLC