From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29680 invoked by alias); 15 Sep 2008 03:00:58 -0000 Received: (qmail 29672 invoked by uid 22791); 15 Sep 2008 03:00:57 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Sep 2008 03:00:14 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 3EE1F17F5F5 for ; Sun, 14 Sep 2008 23:44:53 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m8F30GJw4001898 for ; Mon, 15 Sep 2008 00:00:16 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8F308Jg032372 for ; Mon, 15 Sep 2008 00:00:08 -0300 Received: from [9.8.5.193] ([9.8.5.193]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8F307FU031703; Mon, 15 Sep 2008 00:00:08 -0300 Subject: Re: [RFC] PowerPC prologue unwinder / epilogue detection improvements From: Thiago Jung Bauermann To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org In-Reply-To: <20071206214120.GA26771@caradoc.them.org> References: <20071206214120.GA26771@caradoc.them.org> Content-Type: text/plain; charset=utf-8 Date: Mon, 15 Sep 2008 03:00:00 -0000 Message-Id: <1221447585.2855.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00331.txt.bz2 (Leaving a lot of the context since this e-mail is from so long ago.) El jue, 06-12-2007 a las 16:41 -0500, Daniel Jacobowitz escribió: > The patch also contains two things that are not straightforward and I > am not going to commit as they are: > > - Both the oldish MontaVista toolchain their customer was using, and > the Debian Sarge toolchain on the test machine I used for the port > to HEAD GDB, are built with GCC 3.4. There's an annoying bug in > this version of GCC. Given a sequence like this: > > stwu r1,-48(r1) > mflr r0 > bl 0x26384 > stw r0,52(r1) > ... > > GCC will not report the move of the return address from LR to r0. > It leaves the return address column pointing at LR until the end of > the prologue, and then updates it to point directly at 52(r1) on the > stack. > > I forcibly detect this case in the patch below and use the prologue > unwinder instead of the DWARF-2 unwinder if the prologue contains a > bl instruction (-fpic or -fPIC). This is much too heavy-handed. Is > it worth working around this bug in GDB? > > If so, we should find a way to limit it to some likely selection of > GCC-generated objects. If not - my inclination is not - I'll simply > drop this part of the patch. Anyone who needs it can find it in the > list archives. This is not a problem which affects me, but I wonder: Is it an option to look at the DW_AT_producer for the CU in question and enable the hack only for GCC 3.4? If there's no .debug_info section available, then oh well, we tried... -- []'s Thiago Jung Bauermann IBM Linux Technology Center