From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1812 invoked by alias); 1 Aug 2005 21:08:00 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 1723 invoked by uid 22791); 1 Aug 2005 21:07:55 -0000 Received: from mxfep01.bredband.com (HELO mxfep01.bredband.com) (195.54.107.70) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 01 Aug 2005 21:07:54 +0000 Received: from efd.lth.se ([217.215.11.93] [217.215.11.93]) by mxfep01.bredband.com with SMTP id <20050801210752.CHSB11632.mxfep01.bredband.com@efd.lth.se> for ; Mon, 1 Aug 2005 23:07:52 +0200 From: Stefan =?ISO-8859-15?Q?Burstr=F6m?= To: gdb@sources.redhat.com Date: Mon, 01 Aug 2005 21:08:00 -0000 Message-ID: <33e25af8b96.3a2c2bf5@mail.m.bonet.se> In-Reply-To: <20050801205053.GA19971@nevyn.them.org> Subject: Re: rs6000 / ppc backend in gdb MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2005-08/txt/msg00006.txt.bz2 Hello Daniel On 2005-08-01, you wrote: > On Mon, Aug 01, 2005 at 09:32:59PM +0100, Stefan Burstr=F6m wrote: > Why can't you use the prologue analyzer in this case? You don't have > symbols at the start of functions? Well, in that case, there's not Correct.=20 > much to be done - what will happen is GDB will find the nearest > plausible symbol, decide that's the start of the function, and prologue > analyze from there. If that is a frameless function, and the function > you're really in isn't frameless, you'll lose. However, I don't like to loose :-) > If you have any bright ideas for handling this without breaking the > common case, please do share. Well, for a start, looking at the 'frameless' flag in the frame structure is a good indication that gdb was able to resolve the frame or not. Currently all instances where framless =3D 0 works, so I was thinking of adding assumptions of the stackframe only when this flag is 1 > Yes, I think that's fairly lame, but I'm not familiar with the PPC > backend at all. Yep, indeed it is lame. But indeed it could be helpfull when no prologue is found. Also, assuming that lr is stored at (sp+4) seems alot less harmfull than assuming that sp_prev is stored at (sp) :-) I'll play around with the ppc backend abit but it would be really helpful if someone with some knowledge of that backend could email me. Thanks! regards, Stefan Burstrom