This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]