From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29547 invoked by alias); 1 Apr 2005 14:08:22 -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 28908 invoked from network); 1 Apr 2005 14:08:15 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 Apr 2005 14:08:15 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DHMqA-0008HA-UY; Fri, 01 Apr 2005 09:09:39 -0500 Date: Fri, 01 Apr 2005 14:08:00 -0000 From: Daniel Jacobowitz To: Daniel THOMPSON Cc: gdb@sources.redhat.com Subject: Re: gdbserver, NPTL pthreads and PEEKUSER based targets Message-ID: <20050401140938.GA29152@nevyn.them.org> Mail-Followup-To: Daniel THOMPSON , gdb@sources.redhat.com References: <424C1A88.3000701@st.com> <20050331155058.GA5547@nevyn.them.org> <424D02C8.7040307@st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424D02C8.7040307@st.com> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-04/txt/msg00002.txt.bz2 On Fri, Apr 01, 2005 at 09:14:00AM +0100, Daniel THOMPSON wrote: > 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. Then probably not. You may have a broken PTRACE_SINGLESTEP; I know I've had to fix the SH kernel support in the past. More likely it's something completely different. > 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? More likely, this is a completely different problem. You may have hit the situation where gdbserver has not yet attached to a thread, but another thread hitting a breakpoint has caused it to exit. Gdbserver needs to use PTRACE_SETOPTIONS to attach to new threads; GDB was recently changed to do this. I thought I had some code lying around for this, but I can't find it now. -- Daniel Jacobowitz CodeSourcery, LLC