From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16920 invoked by alias); 31 Mar 2005 15:43:21 -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 16837 invoked from network); 31 Mar 2005 15:43:13 -0000 Received: from unknown (HELO fra-del-04.spheriq.net) (195.46.51.100) by sourceware.org with SMTP; 31 Mar 2005 15:43:13 -0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-04.spheriq.net with ESMTP id j2VFhDoL019648 for ; Thu, 31 Mar 2005 15:43:13 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-03.spheriq.net with ESMTP id j2VFhC2M012529 for ; Thu, 31 Mar 2005 15:43:12 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id j2VFhB50004104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 31 Mar 2005 15:43:12 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 CFE03DA41 for ; Thu, 31 Mar 2005 15:43:07 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 4ACAE4752E; Thu, 31 Mar 2005 15:44:21 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0F6407599B for ; Thu, 31 Mar 2005 15:44:21 +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 47D6B474CD for ; Thu, 31 Mar 2005 15:44:20 +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 BBN00776 (AUTH "daniel thompson"); Thu, 31 Mar 2005 16:43:05 +0100 (BST) Message-ID: <424C1A88.3000701@st.com> Date: Thu, 31 Mar 2005 15:43: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: gdb@sources.redhat.com Subject: gdbserver, NPTL pthreads and PEEKUSER based targets 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-03/txt/msg00320.txt.bz2 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) 1000 Aztec West, Almondsbury, Bristol, BS32 4SQ. 01454 462659 If a car is a horseless carriage then is a motorcycle a horseless horse?