This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdbserver, NPTL pthreads and PEEKUSER based targets
- From: Daniel THOMPSON <daniel dot thompson at st dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 01 Apr 2005 09:14:00 +0100
- Subject: Re: gdbserver, NPTL pthreads and PEEKUSER based targets
- Organization: STMicroelectronics (R&D) Ltd
- References: <424C1A88.3000701@st.com> <20050331155058.GA5547@nevyn.them.org>
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?