This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: multithreading and gdbserver
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Frank van Eijkelenburg <frank dot van dot eijkelenburg at technolution dot nl>
- Cc: Gnu Debugger mailing list <gdb at sources dot redhat dot com>
- Date: Mon, 20 Jan 2003 11:36:14 -0500
- Subject: Re: multithreading and gdbserver
- References: <JJEILELDMJJENLCGJHOIKEECCEAA.frank.van.eijkelenburg@technolution.nl>
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