From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2005 invoked by alias); 20 Jan 2003 16:36:07 -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 1992 invoked from network); 20 Jan 2003 16:36:07 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 20 Jan 2003 16:36:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18agmw-0001Ei-00; Mon, 20 Jan 2003 12:36:50 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18aeuE-0006ud-00; Mon, 20 Jan 2003 11:36:14 -0500 Date: Mon, 20 Jan 2003 16:36:00 -0000 From: Daniel Jacobowitz To: Frank van Eijkelenburg Cc: Gnu Debugger mailing list Subject: Re: multithreading and gdbserver Message-ID: <20030120163614.GB26444@nevyn.them.org> Mail-Followup-To: Frank van Eijkelenburg , Gnu Debugger mailing list References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00348.txt.bz2 On Mon, Jan 20, 2003 at 04:32:39PM +0100, Frank van Eijkelenburg wrote: > Hi, I was wondering if there is anyone who tried remote debbuging a > multithreaded program. I'm using gdb 5.3. I've two linux machines with > redhat installed. If I run gdb and debug a simple multithreaded program > (which is linked against the libpthread library), everything is okay: > > But when I try to debug the same application remote, I can't see any > information about the threads anymore. So, did anyone tried this before? > Output with remote debugging: > > On REMOTE machine: > [frank@vmware frank]$ ./gdbserver host:5555 ex1 > Process ex1 created; pid = 1034 > Remote debugging from host 172.16.10.119 > > On HOST machine: > [frank@frankVMLinux gdb]$ ./gdb -nx /home/frank/tmp/example_i686/ex1 > GNU gdb 5.3 > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu"... > (gdb) target remote 172.16.10.147:5555 > Remote debugging using 172.16.10.147:5555 > 0x40001e20 in ?? () > (gdb) list > 17 return NULL; > 18 } > 19 > 20 int main(void) > 21 { > 22 int retcode; > 23 pthread_t th_a, th_b; > 24 void * retval; > 25 > 26 retcode = pthread_create(&th_a, NULL, process, (void *) "a"); > (gdb) b 26 > Breakpoint 1 at 0x80485d2: file ex1.c, line 26. > (gdb) handle SIG32 nostop > Signal Stop Print Pass to program Description > SIG32 No Yes Yes Real-time event 32 > (gdb) handle SIG32 noprint > Signal Stop Print Pass to program Description > SIG32 No No Yes Real-time event 32 > (gdb) c > Continuing. > > Breakpoint 1, main () at ex1.c:26 > 26 retcode = pthread_create(&th_a, NULL, process, (void *) "a"); > (gdb) n > 27 if (retcode != 0) fprintf(stderr, "create a failed %d\n", > retcode); > (gdb) n > 28 retcode = pthread_create(&th_b, NULL, process, (void *) "b"); > (gdb) info threads > 1 Thread 1034 main () at ex1.c:28 > (gdb) n > 29 if (retcode != 0) fprintf(stderr, "create b failed %d\n", > retcode); > (gdb) n > 30 retcode = pthread_join(th_a, &retval); > (gdb) n > 31 if (retcode != 0) fprintf(stderr, "join a failed %d\n", retcode); > (gdb) n > 32 retcode = pthread_join(th_b, &retval); > (gdb) n > 33 if (retcode != 0) fprintf(stderr, "join b failed %d\n", retcode); > (gdb) n > 34 return 0; > (gdb) info threads > 1 Thread 1034 main () at ex1.c:34 > (gdb) c > Continuing. > > Program exited normally. > (gdb) > > As you can see, there is no information about other threads (except the main > thread). It also didn't tell the user that a thread is created. Why is this > in the first case working and with remote debugging not anymore. If somebody > can explain this, I would really appreciate that... Then it isn't working in your setup. This generally means that gdbserver was not linked to libthread_db, or that you didn't give GDB on the host access to a copy of the libraries on the target. Run with "set debug remote 1" and send a log to the list, please. [Comment: I really need to write better documentation about this and implement better error checking and warnings in the stub; this is definitely one of our most FAQ nowadays.] -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer