From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20690 invoked by alias); 29 Jan 2006 23:21:41 -0000 Received: (qmail 20681 invoked by uid 22791); 29 Jan 2006 23:21:40 -0000 X-Spam-Check-By: sourceware.org Received: from gum.itee.uq.edu.au (HELO gum.itee.uq.edu.au) (130.102.66.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 29 Jan 2006 23:21:38 +0000 Received: from filter2.itee.uq.edu.au (filter2.itee.uq.edu.au [130.102.66.22]) by gum.itee.uq.edu.au (8.12.11/8.12.11) with ESMTP id k0TNLXbY004658 for ; Mon, 30 Jan 2006 09:21:33 +1000 (EST) Received: from nut.itee.uq.edu.au (nut.itee.uq.edu.au [130.102.66.13]) by filter2.itee.uq.edu.au (8.13.1/8.12.11) with ESMTP id k0TNLSOU012040 for ; Mon, 30 Jan 2006 09:21:28 +1000 Received: from [130.102.67.75] (IDENT:U2FsdGVkX1/kxKQ1wFK2HyDR7XM141AQGGMOHgkq6UU@g512-9423.itee.uq.edu.au [130.102.67.75]) by nut.itee.uq.edu.au (8.12.10/8.12.9) with ESMTP id k0TNLSHw016501 for ; Mon, 30 Jan 2006 09:21:28 +1000 (EST) Message-ID: <43DD4DF8.2010203@itee.uq.edu.au> Date: Mon, 30 Jan 2006 08:22:00 -0000 From: John Williams User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050723 Red Hat/1.7.10-1.1.3.1.centos3 MIME-Version: 1.0 To: gdb@sourceware.org Subject: gdbserver+pthreads requires PTHREACE_SINGLESTEP? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checked: This message probably not SPAM X-Spam-Score: 0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00325.txt.bz2 Hello, Am I correct in thinking that the thread debug support in gdbserver requires the kernel to implement the PTRACE_SINGLESTEP functionality? I'm slowly coming to grips with the thread debug mechanism - it seems that gdbserver inserts "private" breakpoints in the child's thread library (e.g. create_thread) - when these breakpoints trigger, gdbserver handles them itself as thread events, rather than passing them off to gdb. The singlestep seems to be necessary because when, say , the create_thread BP is hit, gdbserver wants to step over the first instruction, reinsert the breakpoint, then continue as before. This creates a bit of a bind for me, since the CPU I'm targetting has no HW single step capability - ptrace(PTRACE_SINGLESTEP) returns -EIO. Is there a workaround for non-singlestep targets, short of doing a full kernel SW implementation of single stepping (yuck)? Since it's not really singlestep I need, but rather "continue and reinsert", I wonder if that might be a simpler mechanism to implement? Thanks for any insights, John