PPC stack trace

PPC stack trace

[Stefan Burström]

HHello!
I am currently porting gdb6.3 to AmigaOS4 and I am having some issues with
stack traces on PPC. If I try to trace the stack through a function that
does not include debug info, then the stack trace stops complaining that the
previous frame is identical to this frame. Is this a know problem for the
PPC version of gdb?

I can provide quite accurate logs if someone is interested...

Any ideas?

regards,
Stefan Burström

(ps. I tried to send this email to gdb-prs but that email just bounced)

rs6000 / ppc backend in gdb

[Stefan Burström]

Hello!

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.

best regards,
Stefan Burstrom

Re: rs6000 / ppc backend in gdb

[Daniel Jacobowitz]

On Sun, Jul 31, 2005 at 01:06:47AM +0100, Stefan Burström wrote:
> Hello!
> 
> 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.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: rs6000 / ppc backend in gdb

[Stefan Burström]

Hello Daniel

On 2005-07-31, you wrote:

> On Sun, Jul 31, 2005 at 01:06:47AM +0100, Stefan Burström wrote:
>> Hello!
>> 
>> 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); 
void func2(void); 
  
void func3(void) 
{ 
  printf("func3\n"); 
} 
  
void func1(void) 
{ 
  func2(); 
} 
int main(void) 
{ 
  func1(); 
  return 0; 
} 
void dummyfunc(void) 
{ 
  
} 
void func2(void) 
{ 
  func3(); 
}


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 ()  
(gdb) bt  
#0  0x10000434 in func3 ()  
#1  0x100004f8 in dummyfunc ()  
#2  0x100004f8 in dummyfunc ()  
#3  0x100004f8 in dummyfunc ()  
#4  0x100004f8 in dummyfunc ()  
#5  0x100004f8 in dummyfunc ()  
Previous frame inner to this frame (corrupt stack?) 

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 ()  
(gdb) bt  
#0  0x00401066 in func3 () 
#1  0x004010bb in dummyfunc () 
#2  0x0040107f in func1 () 
#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

Re: rs6000 / ppc backend in gdb

[Daniel Jacobowitz]

On Sun, Jul 31, 2005 at 11:02:36PM +0100, Stefan Burström wrote:
> 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?

No, absolutely they aren't!  We've learned, over years of debugging
people's real code, that trusting the architecture defined stack layout
is not a good choice.  For instance, on x86 -fomit-frame-pointer is
popular to free up an additional register.

You weren't very specific about what versions you were testing, but on
x86 you've probably got DWARF2 CFI available, which allows reliable
unwinding without prologue analysis.  On PPC we don't support DWARF2
CFI yet; until recently, GCC wrote out buggered CFI in which LR and
another register had the same register number.  That's been fixed, but
to turn on PPC CFI support we'd need to detect and work around it, and
no one's implemented that yet.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: rs6000 / ppc backend in gdb

[Stefan Burström]

Hello Daniel

On 2005-08-01, you wrote:

> On Sun, Jul 31, 2005 at 11:02:36PM +0100, Stefan Burström wrote:
>
> No, absolutely they aren't!  We've learned, over years of debugging
> people's real code, that trusting the architecture defined stack layout

Well, if you don't have any debugging info available then?

> is not a good choice.  For instance, on x86 -fomit-frame-pointer is
> popular to free up an additional register.

Well, I see a lot of problems on architectures where you cannot determine
the layout of the stackframe. But on those architectures you are completely
screwed anyway without debug info

> You weren't very specific about what versions you were testing, but on
> x86 you've probably got DWARF2 CFI available, which allows reliable

Well, the problem is not when debug info is available. The problem is if the
stack chain goes through the OS where no debug info at all is available. 

I suppose I am pretty much on my own if I want to get this functionality
into GDB?

One interesting thing about all this is that even if the PPC backend tries
to be really nice and look at the prologue to determine various aspects of
the frame, it still assumes that the previous sp is saved where the current
sp points.

regards,
Stefan Burstrom

Re: rs6000 / ppc backend in gdb

[Daniel Jacobowitz]

On Mon, Aug 01, 2005 at 09:32:59PM +0100, Stefan Burström wrote:
> Well, the problem is not when debug info is available. The problem is if the
> stack chain goes through the OS where no debug info at all is available. 
> 
> I suppose I am pretty much on my own if I want to get this functionality
> into GDB?

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
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.

If you have any bright ideas for handling this without breaking the
common case, please do share.

> One interesting thing about all this is that even if the PPC backend tries
> to be really nice and look at the prologue to determine various aspects of
> the frame, it still assumes that the previous sp is saved where the current
> sp points.

Yes, I think that's fairly lame, but I'm not familiar with the PPC
backend at all.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: rs6000 / ppc backend in gdb

[Stefan Burström]

Hello Daniel

On 2005-08-01, you wrote:

> On Mon, Aug 01, 2005 at 09:32:59PM +0100, Stefan Burström 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. 

> 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 = 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