This is the mail archive of the
mailing list for the GDB project.
Re: gdbserver/gdb-6/4 and lots of pthreads
After working through a couple of configure bugs (configure #defines
HAVE_TD_THR_TLS_GET_ADDR to 1 even when the test properly fails), I
still seem to have the same symptoms.
I have noticed that I now hit the default clause in the ptrace system
call handler a few times - because there is not a case for
PTRACE_GETSIGINFO in linux 2.6.10). Is this a/the problem? In the mean
time, I'll trying to locate a definition for that case and make it work
on my architectures.
Daniel, is any settings and/or initialization things that I need to do
in order to make use of your patch?
Sent: Wed, 15 Nov 2006 11:49 AM
Subject: Re: gdbserver/gdb-6/4 and lots of pthreads
On Wed, Nov 15, 2006 at 11:11:45AM -0500, firstname.lastname@example.org wrote:
Gdbserver attaches to my main thread and opens a socket, and then
invoking gdb and specifying my remote target, I select the
thread that I wish to debug. Info threads shows all of my threads,
I see that gdbserver now attaches to all of them.
Normally this is a feature :-)
Any attempt to single-step or continue with a breakpoint results in
"thrashing system". A counter in my context switching code shows
150k switchs/second, up from about 1200/sec when not attached with
One of the 40 pthreads handle a 10ms SIGALRM. Almost all of the
are waiting for messages.
It'll be the 10ms SIGALRM. Fortunately, I have _just_ the thing for
you. If you can wait another day or two, I expect to commit a patch
which dramatically improves gdbserver performance for multithreaded
applications with signals ignored by GDB. You can find the patch on
the gdb-patches list archives if you want to try it in the mean time;
it should apply to a checkout of current CVS HEAD. You need a patched
gdbserver and gdb client.
Check Out the new free AIM(R) Mail -- 2 GB of storage and
industry-leading spam and email virus protection.