Re: rs6000 / ppc backend in gdb

["Stefan Burström" <f94sbu@efd.lth.se>]

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