gdbserver, NPTL pthreads and PEEKUSER based targets

[Daniel Jacobowitz]

On Fri, Apr 01, 2005 at 09:14:00AM +0100, Daniel THOMPSON wrote:
> Daniel Jacobowitz wrote:
> >>Unfortunately the gdbserver bails out inside pthread_create() with an 
> >>SIGTRAP signal.
> >
> >That will be an unrelated problem.  It sounds like you may need a
> >reinsert_addr method.
> 
> I not quite sure about this, primarily because the SH4 kernel supports 
> PTRACE_SINGLESTEP since it has h/ware to assist this.

Then probably not.  You may have a broken PTRACE_SINGLESTEP; I know
I've had to fix the SH kernel support in the past.  More likely it's
something completely different.

> Running with strace shows the following assuming the debug threads 
> output and the ptrace output are correctly interleaved (pids have 
> changed because this is a different gdbserver session):
> 
> | Resuming process 309 (step, signal 0, stop not expected)
> |   pending reinsert at 2957c8a0
> | Checking for breakpoint.
> | ptrace(PTRACE_PEEKTEXT, 309, 0x2957c8a0, [0x4f222fe6]) = 0
> | Removed breakpoint.
> | <most of the boring PTRACE_POKEUSERs to keep this mail small>
> | ptrace(PTRACE_POKEUSER, 309, 4*REG_PC, 0x2957c8a0) = 0
> | ptrace(PTRACE_POKEUSER, 309, 4*REG_PR, 0x2957dc4c) = 0
> | ptrace(PTRACE_POKEUSER, 309, 4*REG_GBR, 0x296b27a8) = 0
> | ptrace(PTRACE_SINGLESTEP, 309, 0, SIG_0) = 0
> | --- SIGCHLD (Child exited) @ 0 (0) ---
> | --- SIGCHLD (Child exited) @ 0 (0) ---
> | Got an event from 310 (5)
> | Thread 703277904 (LWP 310) exiting
> | Got an event from 309 (5)
> | Thread 694887272 (LWP 309) exiting
> 
> This smells to me like a kernel bug in PTRACE_SINGLESTEP. Has the kernel 
> failed to apply the signal mask?

More likely, this is a completely different problem.  You may have hit
the situation where gdbserver has not yet attached to a thread, but
another thread hitting a breakpoint has caused it to exit.  Gdbserver
needs to use PTRACE_SETOPTIONS to attach to new threads; GDB was
recently changed to do this.

I thought I had some code lying around for this, but I can't find it
now.

-- 
Daniel Jacobowitz
CodeSourcery, LLC