From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11294 invoked by alias); 1 Apr 2005 08:14:37 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11135 invoked from network); 1 Apr 2005 08:14:22 -0000 Received: from unknown (HELO lon-del-01.spheriq.net) (195.46.50.97) by sourceware.org with SMTP; 1 Apr 2005 08:14:22 -0000 Received: from lon-out-01.spheriq.net ([195.46.50.129]) by lon-del-01.spheriq.net with ESMTP id j318EIoG006800 for ; Fri, 1 Apr 2005 08:14:18 GMT Received: from lon-cus-02.spheriq.net (lon-cus-02.spheriq.net [195.46.50.38]) by lon-out-01.spheriq.net with ESMTP id j318EII4002942 for ; Fri, 1 Apr 2005 08:14:18 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by lon-cus-02.spheriq.net with ESMTP id j318EG8E013223 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 1 Apr 2005 08:14:17 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0B0C1DA53; Fri, 1 Apr 2005 08:14:07 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 70DF247351; Fri, 1 Apr 2005 08:15:18 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 1E1607599B; Fri, 1 Apr 2005 08:15:18 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 04A1747360; Fri, 1 Apr 2005 08:15:16 +0000 (GMT) Received: from [164.129.15.35] (butch.bri.st.com [164.129.15.35]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id BBN04685 (AUTH "daniel thompson"); Fri, 1 Apr 2005 09:14:00 +0100 (BST) Message-ID: <424D02C8.7040307@st.com> Date: Fri, 01 Apr 2005 08:14:00 -0000 From: Daniel THOMPSON Organization: STMicroelectronics (R&D) Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Fedora/1.7.6-1.3.2 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gdbserver, NPTL pthreads and PEEKUSER based targets References: <424C1A88.3000701@st.com> <20050331155058.GA5547@nevyn.them.org> In-Reply-To: <20050331155058.GA5547@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: No X-SpheriQ-Ver: 2.1.1 X-SW-Source: 2005-04/txt/msg00001.txt.bz2 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. | | 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) 1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659 If a car is a horseless carriage then is a motorcycle a horseless horse?