Re: gdbserver, NPTL pthreads and PEEKUSER based targets

[Daniel THOMPSON <daniel.thompson@st.com>]

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.

I turned on debug_threads and it appears to have failed while the 
breakpoint was temporarily removed:

| Resuming, no pending status
| Got an event from 342 (57f)
| Hit a (non-reinsert) breakpoint.
| Thread creation event.
| Writing 00 to 29eb2d54
| Writing 00 to 2958b1b8
| Attaching to thread 703277904 (LWP 343)
| Writing 01 to 29eb2d30
| Writing ffffffe6 to 2957c8a0
| Resuming process 342 (step, signal 0, stop not expected)
|   pending reinsert at 2957c8a0
| Checking for breakpoint.
| Removed breakpoint.
|   Got an event from 343 (5)
| Thread 703277904 (LWP 343) exiting
| Got an event from 342 (5)
| Thread 694887272 (LWP 342) exiting
|
| Child terminated with signal = 5
|
| Child terminated with signal = 0x5
| GDBserver exiting

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?

>>The other oddity I noted is that where the x86 does a 
>>PTRACE_ATTACH to LWP pid+4 inside pthread_create(), the SH4 is attaching 
>>to LWP pid+1 which does not seem right as this would not be the LWP of 
>>the spawned thread. 
> 
> Why wouldn't it be?

When running an SH4 hosted GDB the lwpid of the spawned thread is always 
pid+3 but gdbserver attaches to pid+1. On x86 hosts GDB the lwpid of the 
spawned thread is always pid+3 and the gdbserver attaches to pid+4. Now 
I realise that the pid offset is different on x86 I guess there's no 
reason for it not to be different on x86.

-- 
Daniel Thompson (STMicroelectronics) <daniel.thompson@st.com>
1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659

If a car is a horseless carriage then is a motorcycle a horseless horse?