From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6673 invoked by alias); 28 Jun 2003 23:54:56 -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 6664 invoked from network); 28 Jun 2003 23:54:55 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 28 Jun 2003 23:54:55 -0000 Received: from dsl093-172-017.pit1.dsl.speakeasy.net ([66.93.172.17] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19WPXq-0007gG-00; Sat, 28 Jun 2003 18:55:50 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19WPWn-0007cX-00; Sat, 28 Jun 2003 19:54:45 -0400 Date: Sun, 29 Jun 2003 02:02:00 -0000 From: Daniel Jacobowitz To: Jon Ringle Cc: gdb@sources.redhat.com Subject: Re: pthread_create does not return when remote debugging Message-ID: <20030628235443.GB28096@nevyn.them.org> Mail-Followup-To: Jon Ringle , gdb@sources.redhat.com References: <200306280128.02056.jon.ringle@comdial.com> <200306281311.06525.jon.ringle@comdial.com> <20030628200150.GA26696@nevyn.them.org> <200306281833.53367.jon.ringle@comdial.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306281833.53367.jon.ringle@comdial.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-06/txt/msg00536.txt.bz2 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2003-06-28 Daniel Jacobowitz * linux-arm-low.c (arm_reinsert_addr): New function. (the_low_target): Add arm_reinsert_addr. Index: linux-arm-low.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/linux-arm-low.c,v retrieving revision 1.5 diff -u -p -r1.5 linux-arm-low.c --- linux-arm-low.c 18 Nov 2002 00:37:50 -0000 1.5 +++ linux-arm-low.c 28 Jun 2003 23:53:49 -0000 @@ -80,6 +80,17 @@ arm_breakpoint_at (CORE_ADDR where) return 0; } +/* We only place breakpoints in empty marker functions, and thread locking + is outside of the function. So rather than importing software single-step, + we can just run until exit. */ +static CORE_ADDR +arm_reinsert_addr () +{ + unsigned long pc; + collect_register_by_name ("lr", &pc); + return pc; +} + struct linux_target_ops the_low_target = { arm_num_regs, arm_regmap, @@ -89,7 +100,7 @@ struct linux_target_ops the_low_target = arm_set_pc, (const char *) &arm_breakpoint, arm_breakpoint_len, - NULL, + arm_reinsert_addr, 0, arm_breakpoint_at, };