From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29118 invoked by alias); 29 Jun 2003 02:02:25 -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 29110 invoked from network); 29 Jun 2003 02:02:24 -0000 Received: from unknown (HELO smtp-out.comcast.net) (24.153.64.116) by sources.redhat.com with SMTP; 29 Jun 2003 02:02:24 -0000 Received: from home.ringle.org (pcp03186657pcs.proctr01.fl.comcast.net [68.56.245.147]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HH8008IA02X1P@mtaout04.icomcast.net> for gdb@sources.redhat.com; Sat, 28 Jun 2003 21:56:57 -0400 (EDT) Received: by home.ringle.org (Postfix, from userid 501) id B3528B8244; Sat, 28 Jun 2003 21:56:49 -0400 (EDT) Date: Sun, 29 Jun 2003 06:40:00 -0000 From: Jon Ringle Subject: Re: pthread_create does not return when remote debugging In-reply-to: <20030628235443.GB28096@nevyn.them.org> To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Message-id: <200306282156.49408.jon.ringle@comdial.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5 References: <200306280128.02056.jon.ringle@comdial.com> <200306281833.53367.jon.ringle@comdial.com> <20030628235443.GB28096@nevyn.them.org> X-SW-Source: 2003-06/txt/msg00538.txt.bz2 On Saturday 28 June 2003 07:54 pm, Daniel Jacobowitz wrote: > On Sat, Jun 28, 2003 at 06:33:53PM -0400, Jon Ringle wrote: > > On Saturday 28 June 2003 04:01 pm, Daniel Jacobowitz wrote: > > > On Sat, Jun 28, 2003 at 01:11:06PM -0400, Jon Ringle wrote: > > > > > > Could the problem be on the gdbserver side not sending back > > > > > > anything in response to gdb Sending packet: &c#63...Ack? > > > > > > > > > > No. That's a continue request. The target isn't stopping again, > > > > > but that's not gdbserver's fault... it won't respond to the client > > > > > until the program stops. > > > > > > > > > > Find out why it's not stopping... > > > > > > > > I turned on remote_debug = 1, and debug_threads = 1 on gdbserver, and > > > > I get the following on the target when I continue. The signal 32 > > > > looks suspect to me. > > > > > > It is correct. The thread manager uses that. What are you running on > > > the ARM board? What's the rest of the gdbserver log? > > > > The ARM board is running linux-2.2.16 w/ glibc-2.1.3. The arm-linux-gcc > > version is 2.95.2. > > Gdbserver is issuing a single-step request. ARM doesn't have > single-step support in hardware, generally, so the kernel emulates it. > This behaviour almost certainly represents a problem with your kernel's > single-step implementation. One possible problem would be if your > compiler is using the "bx" instruction to return from functions; most > versions of the kernel can't single-step a bx instruction. > > Here's a tweak to gdbserver which will prevent it from trying to > single-step in your case. Let me know if this works, please. You da man! It worked. What's interesting though, is that if I used the arm gdb-cross/gdb/gdb on the arm board, this worked just fine. It appears that gdb handles this situation ok as is. Does gdb handle this the way that your patch for gdbserver does? Jon