gdbserver+pthreads requires PTHREACE_SINGLESTEP?

gdbserver+pthreads requires PTHREACE_SINGLESTEP?

[John Williams]

Hello,

Am I correct in thinking that the thread debug support in gdbserver 
requires the kernel to implement the PTRACE_SINGLESTEP functionality?

I'm slowly coming to grips with the thread debug mechanism - it seems 
that gdbserver inserts "private" breakpoints in the child's thread 
library (e.g. create_thread) - when these breakpoints trigger, gdbserver 
handles them itself as thread events, rather than passing them off to gdb.

The singlestep seems to be necessary because when, say , the 
create_thread BP is hit, gdbserver wants to step over the first 
instruction, reinsert the breakpoint, then continue as before.

This creates a bit of a bind for me, since the CPU I'm targetting has no 
HW single step capability -  ptrace(PTRACE_SINGLESTEP) returns -EIO.

Is there a workaround for non-singlestep targets, short of doing a full 
kernel SW implementation of single stepping (yuck)?

Since it's not really singlestep I need, but rather "continue and 
reinsert", I wonder if that might be a simpler mechanism to implement?

Thanks for any insights,

John

Re: gdbserver+pthreads requires PTHREACE_SINGLESTEP?

[Daniel Jacobowitz]

On Mon, Jan 30, 2006 at 09:21:28AM +1000, John Williams wrote:
> Hello,
> 
> Am I correct in thinking that the thread debug support in gdbserver 
> requires the kernel to implement the PTRACE_SINGLESTEP functionality?

No, it does not.  Please look at the reinsert_addr methods, for
instance on MIPS.

> The singlestep seems to be necessary because when, say , the 
> create_thread BP is hit, gdbserver wants to step over the first 
> instruction, reinsert the breakpoint, then continue as before.
> 
> This creates a bit of a bind for me, since the CPU I'm targetting has no 
> HW single step capability -  ptrace(PTRACE_SINGLESTEP) returns -EIO.
> 
> Is there a workaround for non-singlestep targets, short of doing a full 
> kernel SW implementation of single stepping (yuck)?

We can set a temporary breakpoint at the return address.  In general,
that is not viable, but we know that these particular breakpoints are
(A) trivial empty functions, and (B) called by a single thread under
a serializing lock.

-- 
Daniel Jacobowitz
CodeSourcery