From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23074 invoked by alias); 31 Mar 2005 15:49:45 -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 23061 invoked from network); 31 Mar 2005 15:49:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 31 Mar 2005 15:49:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DH1wg-0001Ti-1Z; Thu, 31 Mar 2005 10:50:58 -0500 Date: Thu, 31 Mar 2005 15:49:00 -0000 From: Daniel Jacobowitz To: Daniel THOMPSON Cc: gdb@sources.redhat.com Subject: Re: gdbserver, NPTL pthreads and PEEKUSER based targets Message-ID: <20050331155058.GA5547@nevyn.them.org> Mail-Followup-To: Daniel THOMPSON , gdb@sources.redhat.com References: <424C1A88.3000701@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424C1A88.3000701@st.com> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00321.txt.bz2 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