trouble with gdb backtraces on ppc with gcc4

trouble with gdb backtraces on ppc with gcc4

[Olaf Hering]

the backtraces in gdb 6.3 and also in gdb-mainline are usually broken in
openSuSE. How does gdb generate them? I guess gdb needs to deal with the
gcc generated debug info. It seems this fails in many cases, as a result
I get a loop:

 main.c
#include <stdio.h>
extern int t1(int);
extern int t2(int);
int main(void)
{
	int i = 0;
	while (i++)
		i = t1(i) * t2(i);
	printf("i %d\n", i);
	return 0;
}

 t1.c
#include <stdio.h>
int t1(int i)
{
	printf("i %d\n", i);
	return i + 1;
}
 t2.c
int t2(int i)
{
	return i + 2;
}

 gcc -O1 -g -c *.c -Wall && gcc -o t *.o && /usr/bin/gdb t

r
...
i -1525098859
i -250087813
i -1598913907
i -255915693
i 155071
Program received signal SIGINT, Interrupt.
0x0ff6443c in __write_nocancel () from /lib/tls/libc.so.6
(gdb) bt
#0  0x0ff6443c in __write_nocancel () from /lib/tls/libc.so.6
#1  0x0ff141c4 in _IO_new_file_write () from /lib/tls/libc.so.6
#2  0x0ff126e0 in new_do_write () from /lib/tls/libc.so.6
#3  0x0ff12898 in _IO_new_do_write () from /lib/tls/libc.so.6
#4  0x0ff13424 in _IO_new_file_overflow () from /lib/tls/libc.so.6
#5  0x0ff143f4 in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#6  0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
#7  0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
#8  0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
#9  0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
#10 0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
#11 0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
#12 0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb) 



SLES9 does a better job:

...
i -2042139181
i -1862425
Program received signal SIGINT, Interrupt.
0x0ff6dc10 in __write_nocancel () from /lib/tls/libc.so.6
(gdb) bt
#0  0x0ff6dc10 in __write_nocancel () from /lib/tls/libc.so.6
#1  0x0ff20ee4 in _IO_new_file_write () from /lib/tls/libc.so.6
#2  0x0ff20b34 in new_do_write () from /lib/tls/libc.so.6
#3  0x0ff20e68 in _IO_new_do_write () from /lib/tls/libc.so.6
#4  0x0ff218e8 in _IO_new_file_overflow () from /lib/tls/libc.so.6
#5  0x0ff20db8 in _IO_new_file_xsputn () from /lib/tls/libc.so.6
#6  0x0fefc8f8 in vfprintf () from /lib/tls/libc.so.6
#7  0x0ff0361c in printf () from /lib/tls/libc.so.6
#8  0x100004cc in t1 (i=-1862425243) at t1.c:4
#9  0x10000458 in main () at main.c:8


-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: trouble with gdb backtraces on ppc with gcc4

[Andreas Schwab]

Olaf Hering <olh@suse.de> writes:

> the backtraces in gdb 6.3 and also in gdb-mainline are usually broken in
> openSuSE. How does gdb generate them? I guess gdb needs to deal with the
> gcc generated debug info.

When there is one.  In your example there isn't.  The openSuSE gdb has
been patched to make use of the DWARF unwind information, which works
quite well if it is present.

> (gdb) bt
> #0  0x0ff6443c in __write_nocancel () from /lib/tls/libc.so.6
> #1  0x0ff141c4 in _IO_new_file_write () from /lib/tls/libc.so.6
> #2  0x0ff126e0 in new_do_write () from /lib/tls/libc.so.6
> #3  0x0ff12898 in _IO_new_do_write () from /lib/tls/libc.so.6
> #4  0x0ff13424 in _IO_new_file_overflow () from /lib/tls/libc.so.6
> #5  0x0ff143f4 in _IO_new_file_xsputn () from /lib/tls/libc.so.6
> #6  0x0feeb990 in vfprintf () from /lib/tls/libc.so.6
> #7  0x0feeb990 in vfprintf () from /lib/tls/libc.so.6

No debug info in /lib/tls/libc.so.6.  Will work fine when debug info
exists.

> SLES9 does a better job:

SLES9 has an older compiler, which does less aggressive optimisations.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: trouble with gdb backtraces on ppc with gcc4

[Olaf Hering]

 On Wed, Nov 09, Andreas Schwab wrote:

> Olaf Hering <olh@suse.de> writes:
> 
> > the backtraces in gdb 6.3 and also in gdb-mainline are usually broken in
> > openSuSE. How does gdb generate them? I guess gdb needs to deal with the
> > gcc generated debug info.
> 
> When there is one.  In your example there isn't.  The openSuSE gdb has
> been patched to make use of the DWARF unwind information, which works
> quite well if it is present.

seems to work better.

(gdb) bt
#0  0x0ff6467c in __write_nocancel () from /lib/libc.so.6
#1  0x0ff143a4 in _IO_new_file_write (f=0xffea9b8, data=0x40017000, n=13) at fileops.c:1260
#2  0x0ff128c0 in new_do_write (fp=0xffea9b8, data=0x40017000 "i 1351088395\n\n", to_do=13) at fileops.c:514
#3  0x0ff12a78 in _IO_new_do_write (fp=<value optimized out>, data=<value optimized out>, to_do=13) at fileops.c:486
#4  0x0ff13604 in _IO_new_file_overflow (f=0xffea9b8, ch=-1) at fileops.c:865
#5  0x0ff145d4 in _IO_new_file_xsputn (f=0xffea9b8, data=<value optimized out>, n=1) at fileops.c:1340
#6  0x0feeb9a0 in _IO_vfprintf (s=0xffea9b8, format=0x10000914 "i %d\n", ap=0xffffe450) at vfprintf.c:1565
#7  0x24000484 in ?? ()
#8  0x0fef2c40 in printf (format=<value optimized out>) at printf.c:34
#9  0x100004fc in t1 (i=1351088395) at t1.c:4
#10 0x10000488 in main () at main.c:8

> No debug info in /lib/tls/libc.so.6.  Will work fine when debug info
> exists.

Well done. There is none...

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: trouble with gdb backtraces on ppc with gcc4

[Daniel Jacobowitz]

On Wed, Nov 09, 2005 at 03:02:15PM +0100, Olaf Hering wrote:
>  On Wed, Nov 09, Andreas Schwab wrote:
> 
> > Olaf Hering <olh@suse.de> writes:
> > 
> > > the backtraces in gdb 6.3 and also in gdb-mainline are usually broken in
> > > openSuSE. How does gdb generate them? I guess gdb needs to deal with the
> > > gcc generated debug info.
> > 
> > When there is one.  In your example there isn't.  The openSuSE gdb has
> > been patched to make use of the DWARF unwind information, which works
> > quite well if it is present.

FYI, the reason that GDB doesn't is that until fairly recently, GCC
generated bogus PPC unwind info (had the wrong register number for LR).
Someone ought to see whether it's practical to detect and work around
that case.  Or maybe we should just require fixed debug info now.


-- 
Daniel Jacobowitz
CodeSourcery, LLC