From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17886 invoked by alias); 8 Jan 2004 05:02:06 -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 17797 invoked from network); 8 Jan 2004 05:02:02 -0000 Received: from unknown (HELO desire.geoffk.org) (67.169.96.182) by sources.redhat.com with SMTP; 8 Jan 2004 05:02:02 -0000 Received: from desire.geoffk.org (localhost.localdomain [127.0.0.1]) by desire.geoffk.org (8.12.10/8.12.10) with ESMTP id i0851WQ0016444; Wed, 7 Jan 2004 21:01:32 -0800 Received: (from geoffk@localhost) by desire.geoffk.org (8.12.10/8.12.10/Submit) id i0851VBx016440; Wed, 7 Jan 2004 21:01:31 -0800 Date: Thu, 08 Jan 2004 05:02:00 -0000 From: Geoff Keating Message-Id: <200401080501.i0851VBx016440@desire.geoffk.org> To: amodra@bigpond.net.au CC: cagney@gnu.org, kettenis@chello.nl, gcc-patches@gcc.gnu.org, dje@watson.ibm.com, gdb-patches@sources.redhat.com, Ulrich.Weigand@de.ibm.com In-reply-to: <20040108004849.GR2533@bubble.modra.org> (message from Alan Modra on Thu, 8 Jan 2004 11:18:49 +1030) Subject: Re: Incorrect DWARF-2 register numbers on PPC64? References: <200312182258.hBIMwgT25422@makai.watson.ibm.com> <200312201527.hBKFRHgI000712@elgar.kettenis.dyndns.org> <3FF5A069.1040306@gnu.org> <200401022317.i02NHQBR001191@desire.geoffk.org> <20040106152710.GB2533@bubble.modra.org> <200401071743.i07HhAle000811@elgar.kettenis.dyndns.org> <20040107222907.GO2533@bubble.modra.org> <3FFC97DF.2030009@gnu.org> <20040108004849.GR2533@bubble.modra.org> X-SW-Source: 2004-01/txt/msg00196.txt.bz2 > Date: Thu, 8 Jan 2004 11:18:49 +1030 > From: Alan Modra > > >>This won't work for GDB > > >>since it assumes that CFI uses the same register number encoding as > > >>all the other DWARF 2 debug information. > > > > > > > > >Hmm, I can see that a debugger might reasonably expect .debug_frame > > >to have the same numbers. When I wrote the patch, I was concentrating > > >on .eh_frame rather than .debug_frame, but .debug_frame uses the > > >.eh_frame numbering. It's a little perplexing that dwarf2out.c does > > >this, as it means defining DWARF_FRAME_REGNUM to something other > > >than DBX_REGISTER_NUMBER is useless. DWARF_FRAME_REGNUM ought to > > >just effect .eh_frame. I'm not keen on trying to untangle dwarf2out.c > > >though.. > > > > Is it going to be possible to get this untangled before 3.4 is > > branched/released? > > Hmm, I see gdb looks at .eh_frame as well as .debug_frame, so my idea > of using gcc hard regs for .eh_frame and the proper dwarf regs for > .debug_frame is probably a non-starter anyway. > > The "easy" fix for PPC is to not define DWARF_FRAME_REGNUM so that > .eh_frame and .debug_frame use the reg numbers specified by the ABI, > and to define DWARF_FRAME_REGISTERS as 1232. We can even map "old" > .eh_frame regs using DWARF_REG_TO_UNWIND_COLUMN, so that older libs can > be understood by the unwinder, at least as long as they don't use > altivec regs. > > The only trouble is that this will mean huge unwinder tables. That will also mean that executables built with a new version of GCC won't run on operating systems with an old libgcc. For Darwin, because of historical mistakes involving non-shared libgcc, it will make life very difficult. -- - Geoffrey Keating