Gdb 6.0 attached to some crashed applications refuses to give a meaningful stack trace. Glibc 5.3 does give the right trace (on the same memory image, I detached gdb6 and attach 5.3 and got the right info).. This makes gdb 6 useless in many many situations. It feels like a bug in handling of the signal handlers, but I'm not sure.
please give me an emerge info, try to rebuild binutils and gdb with lesser optimization.
I'm already using pretty conservative settings. I've had the same problem with packages built with binutils-2.14.90.0.7-?? and .8.. but since the exact same binaries work with gdb 5.3.. I dont think its binutils.. If you want I can try compiling with -O0 -march=i386... Portage 2.0.50-r1 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.6.4) ================================================================= System uname: 2.6.4 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz Gentoo Base System version 1.4.3.13 Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s hare/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/ dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/c onfig/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache cvs digest keepdebug sandbox" GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://ade lie.polymtl.ca/ http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/d istributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib alsa apache2 apm avi berkdb bonobo caps cdr crypt cscope cups curl dga doc dvd emacs encode esd ethereal faad foomaticdb gd gdbm geoip gif gnome gp hoto2 gpm gtk gtk2 gtkhtml guile imap imlib java javascript jbig jpeg libg++ lib www mad mikmod mmx mozilla mozp3p mozsvg mpeg mpeg4 mysql ncurses nls nptl offen sive ofx oggvorbis opengl oss pam pdflib png pnp ppds python quicktime readline samba scanner sdl slang speex spell sse ssl tcltk tcpd tetex tiff truetype wavel an wmf x86 xchattext xine xml xml2 xmms xv zlib"
Maybe it uses the libbfd etc from the binutils and there were a problem with that try with -O1 and report back please.
Sorry, doesnt seems to be optimisation based problem.. I ran all three of these against the same libraries, only the "gdb" executable was changed.. I then tried with different compile options of binutils (and different versions .7 and -.8) and it does not seem to have any influence on the output. So I think I'm pretty positive that its a gdb 6 problem... gdb 6.1 (compiled from CVS branch) (gdb) bt #0 0xffffe410 in ?? () #1 0xbfffd20c in ?? () #2 0x00000000 in ?? () #3 0xbfffd140 in ?? () #4 0x40bda413 in __waitpid_nocancel () from /lib/libpthread.so.0 #5 0x40166bc9 in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2. #6 <signal handler called> #7 0x40a54f8d in append_escaped_text () from /usr/lib/libglib-2.0.so.0 #8 0x40a5505b in g_markup_escape_text () from /usr/lib/libglib-2.0.so.0 #9 0x40047a0a in lm_message_node_to_string () from /usr/lib/libloudmouth-1.so.0 #10 0x40047a50 in lm_message_node_to_string () from /usr/lib/libloudmouth-1.so.0 #11 0x40047a50 in lm_message_node_to_string () from /usr/lib/libloudmouth-1.so.0 #12 0x40046022 in lm_connection_send () from /usr/lib/libloudmouth-1.so.0 #13 0x0805badf in chat_composing_send_start_event () #14 0x0805b9bf in chat_composing_start () #15 0x40a0ae23 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #16 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #17 0x40a0a9a9 in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so #18 0x00000000 in ?? () ---Type <return> to continue, or q <return> to quit--- #19 0x00000001 in ?? () #20 0xbfffd8b0 in ?? () #21 0xbfffd7a8 in ?? () #22 0x00000004 in ?? () #23 0x00000000 in ?? () #24 0x40a125a6 in g_type_check_instance_is_a () from /usr/lib/libgobject-2.0.so.0 gdb 5.3 (portage compiled with CFLAGS=-O2 -march=pentium4) I get the same result with my hand build gdb 5.3 (gdb) bt #0 0xffffe410 in ?? () #1 <signal handler called> #2 0x40a54f8d in g_markup_parse_context_get_position () from /usr/lib/libglib-2.0.so.0 #3 0x40a5505b in g_markup_escape_text () from /usr/lib/libglib-2.0.so.0 #4 0x40047a0a in lm_message_node_to_string () from /usr/lib/libloudmouth-1.so.0 #5 0x40047a50 in lm_message_node_to_string () from /usr/lib/libloudmouth-1.so.0 #6 0x40047a50 in lm_message_node_to_string () from /usr/lib/libloudmouth-1.so.0 #7 0x40046022 in lm_connection_send () from /usr/lib/libloudmouth-1.so.0 #8 0x0805badf in gossip_chat_get_type () #9 0x0805b9bf in gossip_chat_get_type () #10 0x40a0ae23 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #11 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0x40a0a9a9 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #13 0x40a09a8b in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #14 0x40a09cb7 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #15 0x405a1185 in gtk_text_buffer_set_text () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x40537171 in _gtk_marshal_VOID__BOXED_STRING_INT () from /usr/lib/libgtk-x11-2.0.so.0 #17 0x409f9db4 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #18 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #19 0x40a0a481 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #20 0x40a09a8b in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #21 0x40a09cb7 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #22 0x405a1297 in gtk_text_buffer_set_text () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x405a1604 in gtk_text_buffer_insert_interactive () from /usr/lib/libgtk-x11-2.0.so.0 #24 0x405a16c4 in gtk_text_buffer_insert_interactive_at_cursor () from /usr/lib/libgtk-x11-2.0.so.0 #25 0x405c8807 in gtk_text_view_get_default_attributes () from /usr/lib/libgtk-x11-2.0.so.0 #26 0x40a0b70c in g_cclosure_marshal_VOID__STRING () from /usr/lib/libgobject-2.0.so.0 #27 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #28 0x40a0a9a9 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #29 0x40a09a8b in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #30 0x40a09d91 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #31 0x4051b603 in gtk_im_multicontext_new () from /usr/lib/libgtk-x11-2.0.so.0 #32 0x40a0b70c in g_cclosure_marshal_VOID__STRING () from /usr/lib/libgobject-2.0.so.0 #33 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #34 0x40a0a9a9 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #35 0x40a09a8b in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #36 0x40a09d91 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #37 0x405197c8 in gtk_im_context_simple_new () from /usr/lib/libgtk-x11-2.0.so.0 #38 0x40519ac9 in gtk_im_context_simple_new () from /usr/lib/libgtk-x11-2.0.so.0 #39 0x40519daf in gtk_im_context_simple_new () from /usr/lib/libgtk-x11-2.0.so.0 #40 0x40518f3e in gtk_im_context_filter_keypress () from /usr/lib/libgtk-x11-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #41 0x4051b2e1 in gtk_im_multicontext_new () from /usr/lib/libgtk-x11-2.0.so.0 #42 0x40518f3e in gtk_im_context_filter_keypress () from /usr/lib/libgtk-x11-2.0.so.0 #43 0x405c4385 in gtk_text_view_place_cursor_onscreen () from /usr/lib/libgtk-x11-2.0.so.0 #44 0x40535dd6 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #45 0x409f9db4 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #46 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #47 0x40a0a481 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #48 0x40a09878 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #49 0x40a09cb7 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #50 0x4060b6c3 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #51 0x40617d37 in _gtk_window_query_nonaccels () from /usr/lib/libgtk-x11-2.0.so.0 #52 0x40535dd6 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0 #53 0x409f9db4 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #54 0x409f9a87 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #55 0x40a0a481 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0 #56 0x40a09878 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #57 0x40a09cb7 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #58 0x4060b6c3 in gtk_widget_send_expose () from /usr/lib/libgtk-x11-2.0.so.0 #59 0x40535c6c in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #60 0x40534a93 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #61 0x406ddcd8 in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #62 0x40a4fd15 in unblock_source () from /usr/lib/libglib-2.0.so.0 #63 0x40a50c77 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #64 0x40a50f70 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #65 0x40a515f8 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #66 0x40534341 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #67 0x08065b20 in main () #68 0x40c1681a in __libc_start_main () from /lib/libc.so.6 gdb 6.0 (from portage with CFLAGS=-O1) (gdb) bt #0 0xffffe410 in ?? () #1 0xbfffd20c in ?? ()
I also get this problem: debug a program with abort() called. The stack trace will be rubbish. I see gdb 6.1 is at: http://ftp.gnu.org/gnu/gdb/ I will give that a go. If it works I will add to to portage ~x86 only.
Ok, the results: I tried gdb 5.3 and 6.1 6.1 produces the same error, 5.3 works. Will now try gdb CVS
Hello, I did a bit more experimenting with some Fedora development rpm's. It seems that gdb is not at fault but glibc. I played about with gdb-6.1 (released yesterday) and the system libraries from Fedora. My test case was: int main() { abort(); } and the stack trace it produces apon the abort. The gdb-6.1 binary fails when run in gentoo, but in my chroot fedora system library enviroment it works. I swapped the febora system libraries for the gentoo ones and gdb started failing again. My guess is that glibc needs to be fixed / upgraded as some features are missing for proper debugging. It is strange that your gdb-6.1 CVS worked, can I have the date stamp so I can give it a go here.
I got hold of the current Fedora glibc snapshot. I compiled it and installed it to my test chroot. It solves the problem, I now get the following backtrace at a signal: (gdb) bt #0 0xffffe410 in ?? () #1 0xbffff39c in ?? () #2 0x00000006 in ?? () #3 0x00003b01 in ?? () #4 0x4003fd51 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #5 0x40041412 in *__GI_abort () at ../sysdeps/generic/abort.c:88 #6 0x08048399 in main () or stripped glibc: (gdb) bt #0 0xffffe410 in ?? () #1 0xbffff39c in ?? () #2 0x00000006 in ?? () #3 0x00003bc3 in ?? () #4 0x4003fd51 in raise () from /lib/libc.so.6 #5 0x40041412 in abort () from /lib/libc.so.6 #6 0x08048399 in main () rather than (gdb) bt #0 0xffffe410 in ?? () #1 0xbfffee6c in ?? () #2 0x00000006 in ?? () #3 0x00001701 in ?? () #4 0x4d76bec1 in raise () from /lib/libc.so.6 #5 0x4d76d488 in abort () from /lib/libc.so.6 #6 0xbfffee80 in ?? () #7 0x00000000 in ?? () #8 0x00000020 in ?? () #9 0x00000000 in ?? () much better .. I also did a few tests with glibc with nptl disabled using the glibc's in portage. This also fixed the problem. So the solutions are: 1)Use gdb-5.3. 2)Disable nptl when you compile glibc. 3)Upgrade glibc to glibc-2.3.3-200403251824 (CVS snapshot as glibc is not released anymore) 4)Switch to Fedora. Not sure that 5.3 will handle nptl threads though, so 2 and 3 are the only resonable options. Just have to push the glibc maintainer to do an upgrade / bug fix.
Bug 46186 perhaps ?
Ok found the real solution: CFLAGS="-march=i686 -O3 -pipe" emerge glibc and don't even try to use other CFLAGS! -march=i686 -mcpu=pentium4 fails as does anything higher. Not sure about the stripping mentioned by vaiper, but that makes no difference for this bug. I guess the glibc ebuild needs to fix the CFLAGS and users can just complain ..
what about say -march=pentium4 -O2 ? :)
"what about say -march=pentium4 -O2 ? :)" I have just compleated CFLAGS="-march=pentium4 -O2 -pipe" and it fails like all the rest. As said before it is the -mcpu and -march part of the CFLAGS which are the problem. result: (gdb) bt #0 0xffffe410 in ?? () #1 0xbffff39c in ?? () #2 0x00000006 in ?? () #3 0x000070b9 in ?? () #4 0x40040ec1 in raise () from /lib/libc.so.6 #5 0x40042488 in abort () from /lib/libc.so.6 #6 0xbffff3b0 in ?? () #7 0x00000000 in ?? () #8 0x00000020 in ?? () #9 0x00000000 in ?? () ... #21 0x00000000 in ?? () #22 0x00000000 in ?? () rather than: (gdb) bt #0 0xffffe410 in ?? () #1 0xbfffee6c in ?? () #2 0x00000006 in ?? () #3 0x000070c7 in ?? () #4 0x40053561 in raise () from /lib/libc.so.6 #5 0x40054c42 in abort () from /lib/libc.so.6 #6 0x08048399 in main () The only safe setting is "-march=i686 -O3 -pipe" or lower (I assume). This really needs to be coded into the glibc ebuild or ignore this bug.
still a prob with latest gdb-6.x and glibc ?
Still there with: sys-libs/glibc-2.3.4.20040808 sys-devel/gdb-6.2.1 running the C program: int main() { abort(); return 0; } Though gdb gives a corrupt stack trace. Same fix as stated before, downgrade cflags.
Tested with both: sys-devel/gcc-3.3.4-r1 sys-devel/gcc-3.4.2-r2 Same fix, had to use; CFLAGS="-march=i686 -O3 -pipe" as noted before.
could you try the latest glibc?
Still the same problem: united saj # cat test.c int main() { abort(); return 0; } united saj # gcc test.c -o test united saj # gdb ./test GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/saj/test Program received signal SIGABRT, Aborted. 0xffffe410 in ?? () (gdb) bt #0 0xffffe410 in ?? () #1 0xbfffdc2c in ?? () #2 0x00000006 in ?? () #3 0x0000402f in ?? () #4 0x41042061 in raise () from /lib/tls/libc.so.6 #5 0x4104399c in abort () from /lib/tls/libc.so.6 #6 0xbfffdc40 in ?? () #7 0x00000000 in ?? () #8 0x00000020 in ?? () #9 0x00000000 in ?? () #10 0x00000000 in ?? () #11 0x00000000 in ?? () #12 0x00000000 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () ---Type <return> to continue, or q <return> to quit---q Quit (gdb) united saj # emerge info Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20041102-r0, 2.6.9 i686) [snip] ACCEPT_KEYWORDS="x86 ~x86" CFLAGS="-march=i686 -mcpu=pentium4 -O3 -pipe" You can test locally very easily ...
on ppc is fine =/ I'll try now with the x86
Hi all... I'm getting something similar; wonder if it's the same problem. Using the same procedure and test program as in comment #17, I get: Program received signal SIGABRT, Aborted. 0xffffe410 in ?? () (gdb) bt #0 0xffffe410 in ?? () #1 0xbfffebdc in ?? () #2 0x00000006 in ?? () #3 0x00004f04 in ?? () #4 0xb7edbce1 in ?? () #5 0xb7fc5dec in ?? () #6 0xb8000c80 in ?? () #7 0xbfffed08 in ?? () #8 0xb7edd425 in ?? () #9 0x00000006 in ?? () #10 0xbfffebf0 in ?? () #11 0x00000000 in ?? () #12 0x00000020 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () The backtrace appears to go on forever: at least I've gotten to #1295 before it prints "Cannot access memory at address 0xc0000000" and stops. The function addresses don't stay as 0x0 throughout - it goes back and forth between a bunch of seemingly-random values. My emerge --info: Portage 2.0.51-r8 (default-linux/x86/2004.3, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r6 i686) ================================================================= System uname: 2.6.9-gentoo-r6 i686 AMD Athlon(tm) processor Gentoo Base System version 1.6.8 Python: dev-lang/python-2.2.3-r5,dev-lang/python-2.3.4 [2.3.4 (#1, Jun 17 2004, 02:12:09)] distcc 2.18.2 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.2 [enabled] dev-lang/python: 2.2.3-r5, 2.3.4 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r2, 1.4_p6, 1.9.3, 1.6.3, 1.7.9 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-tbird -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-tbird -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://mirrors.tds.net/gentoo http://open-systems.ufl.edu/mirrors/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://gentoo.osuosl.org/ http://gentoo.ccccom.com" LDFLAGS="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X aalib acl acpi4linux alsa apache2 apm audiofile avi berkdb bitmap-fonts bonobo cdparanoia cdr crypt cups curl directfb dvd dvdr dvdread encode fam fbcon ffmpeg flac flash foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile imagemagick imlib innodb ipv6 jack java joystick jpeg junit kerberos krb4 ldap libcaca libwww mad matroska mikmod mmx mmxext motif mpeg mysql ncurses nls nptl nvidia oggvorbis opengl oss pam pdflib perl pic png python qt quicktime readline rtc samba sasl sdl slang speex spell sqlite sse ssl stencil-buffer svga tcltk tcpd tetex theora tiff truetype ungif usb v4l2 xchattext xfs xml xml2 xv xvid xvmc zlib"
Just tested with glibc-2.3.5-r1 and sys-devel/gdb-6.3-r4 and it works fine now on a number of systems with different with following CFLAGS: CFLAGS="-march=i686 -mtune=pentium4 -O3 -pipe" CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" CFLAGS=" -march=i686 -O3 -pipe" Time to close the bug I think.
cool !
it works because azarah disabled stripping on ld.so i still say gdb is broken :p
