This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
a question about (new behavior with?) gdb
- To: gdb mailing list <gdb at sourceware dot cygnus dot com>
- Subject: a question about (new behavior with?) gdb
- From: Peter Jay Salzman <p at dirac dot org>
- Date: Tue, 14 Aug 2001 11:49:58 -0700
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