a question about (new behavior with?) gdb

[Peter Jay Salzman <p@dirac.org>]

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