Looks like Gentoo gdb doesn't support debugging threaded programs. This applies both to gdb build from gdb-5.1.1-r2.ebuild and from recent (5.2.1) sources. System looks OK: $ ls -l /usr/include/ | grep thread -rw-r--r-- 1 root root 24667 06-11 18:48 pthread.h -rw-r--r-- 1 root root 15261 06-11 18:48 thread_db.h $ ls -l /lib | grep thread -rwxr-xr-x 1 root root 85132 06-11 18:48 libpthread-0.9.so lrwxr-xr-x 1 root root 15 08-06 16:33 libpthread.so -> libpthread.so.0 lrwxrwxrwx 1 root root 17 06-11 18:49 libpthread.so.0 -> libpthread-0.9.so -rwxr-xr-x 1 root root 17180 06-11 18:48 libthread_db-1.0.so lrwxr-xr-x 1 root root 17 08-06 16:32 libthread_db.so -> libthread_db.so.1 lrwxrwxrwx 1 root root 19 06-11 18:49 libthread_db.so.1 -> libthread_db-1.0.so I can't force thread support. There's no magical --enable-threads switch to ./configure, and I can't even find threads check anywhere in configure.in. Help ;)
Looks like Seemant is assigning everything dev-related to me lately per default :). I am afraid I am not the best person to handle this one - don't know much about threads on a system level. Reassigning to bug-wranglers to let somebody more knowledgable of the topic handle it. George
How did you verify that it doesn't support threading? If you are debugging a program that is multi-threaded type "info threads" to see if it recognizes multiple threads. If there is output from "info threads" there is no threading support... if there is output... then there is. Let me know.
I have created the gdb-5.2.1.ebuild During configure I get this... configuring in gdb.threads running /bin/sh ./configure --host=i686-pc-linux-gnu --target=i686-pc-linux- gnu --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info -- datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-nls -- cache-file=../../../config.cache --srcdir=. loading cache ../../../config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking how to run the C preprocessor... (cached) gcc -E checking for pthread.h... yes updating cache ../../../config.cache creating ./config.status creating Makefile creating config.h So far so good... I have other ebuild issues to work through. As soon as I get a working ebuild to test (gdb-5.2.1) I will post on this bug report.
gdb-5.2.1 is currently in portage. Please test and let me know your results. I haven't had a chance to fully test the package yet.
nope -- gdb-5.2.1 still fails. However i think we are looking in the wrong place. My config.log from gdb.threads looks like that one posted before. Everything is OK, but threads still don't work. It might be related to libc package which includes also libpthread. I'm using 'bleeding edge' settings in my make.conf: CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe" CXXFLAGS="-march=i686 -O3 -pipe" ...maybe I just overlocked compiler settings a bit?
Can I see some error messages or log information from a session where you try to debug a multi-threaded program?
It Works! I've tracked this baby down ;) I just changed CFLAGS in make.conf. I've used -O2 rather than -O3, and did 'emerge glibc'. After that (no other packages emerged) gdb started working with threads. Problem lies in a little bit too agresive optimalization. I think that guy responsible for glibc ebuilt could display warning: you're using -O3, that's a bit too high for such essential package as glibc. You may want to recompile it again with -O2 when you feel something relaying on glibc is broken. Or something along those lines... Cool. Gentoo again kicks some serious butt :))
What version of gcc are you using? This bug is not fixed because we have not made any fixes to Gentoo Linux, so I'm reopening it.
Here's output from gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs gcc version 2.95.3 20010315 (release) I closed this bug because I think all we need is a warning (and I remember something about that in make.conf). Optimizing doesn't work well with debugging at all. With threads -- it looks like it is a killer. However if you Gentoo dev guys want to play around with that bug -- I'll be happy to asist :)
There has been a lot of talk about optimization levels ever since I have been working with linux... which has been close to 8 years now... The default optimization level on MOST core packages on every Linux system I have worked on is -O2 (... and I have never had a problem with optimizations at -O2) You are absolutely right about debugging programs with higher optimizations, it won't work the way you want it to most of the time. I think what this thread brings up is a very important issue with Gentoo... We need to set set the record straight with optimizations. People need to understand that just because the default setting in make.conf is -O3, doesn't mean it's the safest setting or the correct setting... If you are debugging, you don't want to be aggressive with optimizations anyway. Stick with -O2 If you just want things to be as stable as possible but you're not necessarily debugging programs, still Stick with -O2. If you want to experiment, the sky's the limit but MOST people have decent luck with -O3. There are no "set" rules for optimization... but if you push too hard... things will break... The version of gcc will also play a role in the success of optimizations. 5 years ago I would have never dreamed of using anything above -O2... If I tried anything more aggressive at that time I would get strange failures all the time... programs that I thought would "speed up" ended up becoming unstable... Anybody else here have personal experiences that might shed some more insight into what a good set of defaults should be? Are there any figureheads in the Linux/GNU/OSS world that have stated their peace on optimizations?
Although gdb will appear to compile with higher optimization set... multi-threaded debugging obviously has troubles when things are set too aggressive. Optimization flag is automatically set to -O2 by the ebuild now.
