From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Jay Salzman To: gdb mailing list Subject: a question about (new behavior with?) gdb Date: Tue, 14 Aug 2001 11:50:00 -0000 Message-id: <20010814114958.A14214@dirac.org> X-SW-Source: 2001-08/msg00132.html i've noticed a change in gdb. consider: 1 #include 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