From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12740 invoked by alias); 12 Apr 2005 07:52:58 -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 12718 invoked from network); 12 Apr 2005 07:52:52 -0000 Received: from unknown (HELO fra-del-03.spheriq.net) (195.46.51.99) by sourceware.org with SMTP; 12 Apr 2005 07:52:52 -0000 Received: from fra-out-03.spheriq.net (fra-out-03.spheriq.net [195.46.51.131]) by fra-del-03.spheriq.net with ESMTP id j3C7qqPZ011532 for ; Tue, 12 Apr 2005 07:52:52 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 j3C7qpld011613 for ; Tue, 12 Apr 2005 07:52:51 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 j3C7qmMm010560 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 12 Apr 2005 07:52:49 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 685E0DA45; Tue, 12 Apr 2005 07:52:41 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 1DEEC47968; Tue, 12 Apr 2005 07:53:59 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id AF36F7599B; Tue, 12 Apr 2005 07:53:58 +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 1AD7A47967; Tue, 12 Apr 2005 07:53:58 +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 BCY01397 (AUTH "daniel thompson"); Tue, 12 Apr 2005 08:52:39 +0100 (BST) Message-ID: <425B7E46.8040408@st.com> Date: Tue, 12 Apr 2005 07:52: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: Claudia Salzberg Cc: drow@false.org, gdb@sources.redhat.com Subject: Re: unable to debug remotely with threads on ppc target with gdb6.1/6.3 References: In-Reply-To: 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/msg00058.txt.bz2 Claudia Salzberg wrote: > I have tried both gdb 6.1 the latest version (6.3) and am trying to debug > a simple threaded program using pthreads remotely. The target board is a > 440GP and the host is an x86 box. I see references to similar problems in > past posts from 12 2004 ( > http://sourceware.org/ml/gdb/2004-12/msg00028.html) but did not see if a > patch was created. No I am not aware of any patch fixing this issue. The problem (as the thread says) is that ps_lgetregs is not implemented inside the gdbserver on PPC (or any other machine that uses PEEKUSER/POKEUSER to access its register sets). You should be able to jury rig a version by copying the code in ppc-linux-nat.c:fill_gregset() into the ps_lgetregs function and modifying the code to target the gdbserver register cache rather then the gdb register cache. There is, of course, a proper to way to do the above but you might want to confirm the above works first ;-) -- 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?