gdbserver, NPTL pthreads and PEEKUSER based targets

gdbserver, NPTL pthreads and PEEKUSER based targets

[Daniel THOMPSON]

Hi folks

I am trying to port gdbserver to work on NPTL kernels on an architecture 
that fetchs registers using PTRACE_PEEKUSER rather than PTRACE_GETREGS 
(in my specific case the SH4).

I have written a hacky but working implementation of ps_lgetregs(). This 
is sufficient to get through he shared library loading without spitting 
out invalid data packets and works well enough for the threads_db code 
to correctly identify the root thread triplet (pid, lwp, tid).

Unfortunately the gdbserver bails out inside pthread_create() with an 
SIGTRAP signal. 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.

I have tried comparing the strace's of gdb vs. gdbserver but did not 
notice anything very useful.

-- 
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?

Re: gdbserver, NPTL pthreads and PEEKUSER based targets

[Daniel Jacobowitz]

On Thu, Mar 31, 2005 at 04:43:04PM +0100, Daniel THOMPSON wrote:
> Hi folks
> 
> I am trying to port gdbserver to work on NPTL kernels on an architecture 
> that fetchs registers using PTRACE_PEEKUSER rather than PTRACE_GETREGS 
> (in my specific case the SH4).
> 
> I have written a hacky but working implementation of ps_lgetregs(). This 
> is sufficient to get through he shared library loading without spitting 
> out invalid data packets and works well enough for the threads_db code 
> to correctly identify the root thread triplet (pid, lwp, tid).

You should be able to provide gregset information even if ptrace can't
fetch them; the ps_lgetregs implementation uses the same machinery, but
it doesn't require the ptrace support.

> 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.

> 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?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: gdbserver, NPTL pthreads and PEEKUSER based targets

[Daniel THOMPSON]

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?

Re: 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