a question about (new behavior with?) gdb

a question about (new behavior with?) gdb

[Peter Jay Salzman]

i've noticed a change in gdb.  consider:

1 #include<stdio.h>
2 int main(void) {
3    printf("hello world\n");
4    return 0;
5 }

when i (s)tepped into line 3, i would see all sorts of glibc functions go
onto the call stack.  ugly stuff like:

#0  __errno_location () at ../sysdeps/generic/errno-loc.c:28
#1  0x4006679d in _IO_vfprintf (s=0x40113920, format=0x80484a4 "z is %d.\n",
ap=0xbffff4c4) at vfprintf.c:242
#2  0x4006f306 in printf (format=0x80484a4 "z is %d.\n") at printf.c:31
#3  0x8048431 in display (z=5) at try1.c:11
#4  0x8048406 in main () at try1.c:6

recently, i've noticed that i don't step into glibc functions anymore.  that
is, stepping into line 3 will leave me in main().

does gdb now know about which functions belong to the C library and ignore
them for stepping purposes?   or is gdb ignoring functions for which it
doesn't have debugging into?

one last question.  i've noticed a new function on the call stack:

(gdb) backtrace
#0  main () at try1.c:5
#1  0x4003e46b in __libc_start_main () from /lib/libc.so.6

i don't remember seeing __libc_start_main() before.  is that a wrapper
function for gdb?  is that what's hiding frames that belong to glibc?

i can't find mention of these two things in the latest changelog supplied by
my debian woody installation of gdb.


sorry if i misused terms; i'm a physicist jim, not a programmer.   i just
happen to use gdb for debugging programs that i write for recreation.

thanks!
pete

-- 
"The following addresses had permanent fatal errors..."      p@dirac.org
                               -- Mailer Daemon              www.dirac.org/p

Re: a question about (new behavior with?) gdb

[Kevin Buettner]

On Aug 14, 11:49am, Peter Jay Salzman wrote:

> does gdb now know about which functions belong to the C library and ignore
> them for stepping purposes?

No.

> or is gdb ignoring functions for which it
> doesn't have debugging into?
                         ^^^^
                         info
Yes.

> one last question.  i've noticed a new function on the call stack:
> 
> (gdb) backtrace
> #0  main () at try1.c:5
> #1  0x4003e46b in __libc_start_main () from /lib/libc.so.6
> 
> i don't remember seeing __libc_start_main() before.  is that a wrapper
> function for gdb?  is that what's hiding frames that belong to glibc?

__libc_start_main() is the glibc function responsible for calling
main().  It is not the reason that you are no longer able to step into
the functions in glibc.  Simply recompiling glibc so that it has
debugging info (line number information and the like) will enable
you to step into these functions again.

Kevin