From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-22311-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 1547 invoked by alias); 31 Jul 2005 22:15:32 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 1531 invoked by uid 22791); 31 Jul 2005 22:15:28 -0000
Received: from mxfep01.bredband.com (HELO mxfep01.bredband.com) (195.54.107.70)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 31 Jul 2005 22:15:28 +0000
Received: from efd.lth.se ([217.215.11.93] [217.215.11.93])
          by mxfep01.bredband.com with SMTP
          id <20050731221526.SVZD11632.mxfep01.bredband.com@efd.lth.se>
          for <gdb@sources.redhat.com>; Mon, 1 Aug 2005 00:15:26 +0200
From: Stefan =?ISO-8859-15?Q?Burstr=F6m?= <f94sbu@efd.lth.se>
To: gdb@sources.redhat.com
Date: Sun, 31 Jul 2005 22:15:00 -0000
Message-ID: <33e11968721.41b5c8f4@mail.m.bonet.se>
In-Reply-To: <20050731011738.GA13782@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-07/txt/msg00274.txt.bz2

Hello Daniel

On 2005-07-31, you wrote:

> On Sun, Jul 31, 2005 at 01:06:47AM +0100, Stefan Burstr=F6m wrote:
>> Hello!
>>=20
>> Who has written the rs6000 backend in gdb? I am having some troubles
>> getting stack tracing to work and I'd like to ask a few in depth
>> questions regarding how the stack is unwound.
>
> You should ask questions on the list.  Most of the stack unwinding in
> recent versions of GDB is not architecture specific.

Ok, thanks. Here goes:
Consider this testprogram:

void func3(void);=20
void func2(void);=20
=20=20
void func3(void)=20
{=20
  printf("func3\n");=20
}=20
=20=20
void func1(void)=20
{=20
  func2();=20
}=20
int main(void)=20
{=20
  func1();=20
  return 0;=20
}=20
void dummyfunc(void)=20
{=20
=20=20
}=20
void func2(void)=20
{=20
  func3();=20
}


Now, if I compile it and do "strip -N func2" and the run it in gdb and do
break func3
r
bt

Then I get this result on PPC:

Breakpoint 1, 0x10000434 in func3 ()=20=20
(gdb) bt=20=20
#0  0x10000434 in func3 ()=20=20
#1  0x100004f8 in dummyfunc ()=20=20
#2  0x100004f8 in dummyfunc ()=20=20
#3  0x100004f8 in dummyfunc ()=20=20
#4  0x100004f8 in dummyfunc ()=20=20
#5  0x100004f8 in dummyfunc ()=20=20
Previous frame inner to this frame (corrupt stack?)=20

Ie, gdb has serious trouble unwinding the stack. Why is this difficult?

If I run the same testprogram on x86 (I have to use strip -N _func2 instead)
I get this result:

Breakpoint 1, 0x00401066 in func3 ()=20=20
(gdb) bt=20=20
#0  0x00401066 in func3 ()=20
#1  0x004010bb in dummyfunc ()=20
#2  0x0040107f in func1 ()=20
#3  0x004010a4 in main ()

Ie, even if #1 is wrong, gdb has no trouble steping over this function
regardless of how the prologe looked of that function.

Clearly, this is a limitation in the ppc backend of gdb. I have reached as
far as I understand that the skip_prologue function is responsible for
figuring out the stack frame of the function. However, why is this needed?
How come gdb does all this? Isn't the position of lr and prev_sp well
defined in the stack frame?

Help! :-)

regards,
Stefan Burstrom