gdb-6.6/ARM/static linking/pthreads

gdb-6.6/ARM/static linking/pthreads

[John Breitenbach]

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

Re: gdb-6.6/ARM/static linking/pthreads

[Daniel Jacobowitz]

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