gdbserver/gdb-6/4 and lots of pthreads

[jbbachky@aim.com]

Hi,
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 
libthread_db.so.

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.