This is the mail archive of the
mailing list for the GDB project.
gdbserver/gdb-6/4 and lots of pthreads
- From: jbbachky at aim dot com
- To: gdb at sources dot redhat dot com
- Date: Wed, 15 Nov 2006 11:11:45 -0500
- Subject: gdbserver/gdb-6/4 and lots of pthreads
I've got an application with about 40 pthreads running under linux
2.6.10 w/glibc-2.2.3, compiled with gcc-3.4.3 running on powerpc (and
eventually a few other architectures). I've been a happy gdb-5.0 user
for a number of years, with my linux kernel(s) performing the
breakpoint removal/replacement on context switches.
I've been hoping to remove that code and let gdb handle when and if to
break based on process id.
In attempting to upgrade to gdb-6.4, I'm afraid that I've run into a
problem which might require some hacking.
Gdbserver attaches to my main thread and opens a socket, and then after
invoking gdb and specifying my remote target, I select the particular
thread that I wish to debug. Info threads shows all of my threads, and
I see that gdbserver now attaches to all of them.
Any attempt to single-step or continue with a breakpoint results in a
"thrashing system". A counter in my context switching code shows almost
150k switchs/second, up from about 1200/sec when not attached with gdb.
One of the 40 pthreads handle a 10ms SIGALRM. Almost all of the others
are waiting for messages.
Is there a fundamental problem with the number of threads and
attaching/detaching/waking them all?
Do I need to continue to "hide" my other threads from gdb/gdbserver?. I
am building with dynamic linking, and gdbserver finds and uses
Thanks for any help or advice.
Check Out the new free AIM(R) Mail -- 2 GB of storage and
industry-leading spam and email virus protection.