gdb-6.6/ARM/static linking/pthreads

Hi,
  I've got a statically linked application with a dozen or
so pthreads 
(nptl in glibc-2.3.6), and want to use gdb to debug it. 
With gdbserver, 
I attach to the specific thread id, and can set a
breakpoint.  However, 
if that breakpoint is hit by another of the pthreads, my
kernel kills 
off all of them.

We had some code in the linux kernel in the past which would
insert and 
remove breakpoints on context switches, and I'd like to know
if that 
needs to get propagated with our kernel upgrade (to 2.6.18)
or is there 
a better way.  Can gdbserver find out about the other
threads, and 
handle the automatic continue if the SIGTRAP is for the
wrong process.  
Or can I do something in the kernel to remove the
breakpoint, 
single-step and restore the breakpoint in the case of the
wrong process id?

Thanks in advance for any advice
John

On Tue, Aug 28, 2007 at 02:00:29PM -0400, John Breitenbach
wrote:
> Hi,
>  I've got a statically linked application with a dozen
or so pthreads (nptl in 
> glibc-2.3.6), and want to use gdb to debug it.  With
gdbserver, I attach to the 
> specific thread id, and can set a breakpoint.  However,
if that breakpoint is 
> hit by another of the pthreads, my kernel kills off all
of them.

You need both gdb and glibc patches to debug a statically
linked
application with pthreads.  You can find them in the
respective list
archives (gdb-patches and libc-alpha) earlier this year. 
CVS
snapshots of both GDB and glibc trunk should work; the glibc
patch
probably applies cleanly to glibc 2.3.6.

-- 
Daniel Jacobowitz
CodeSourcery