Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* multithreading and gdbserver
@ 2003-01-20 15:32 Frank van Eijkelenburg
  2003-01-20 16:36 ` Daniel Jacobowitz
  0 siblings, 1 reply; 2+ messages in thread
From: Frank van Eijkelenburg @ 2003-01-20 15:32 UTC (permalink / raw)
  To: Gnu Debugger mailing list

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:

[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) 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) run
Starting program: /home/frank/tmp/example_i686/ex1
[New Thread 1024 (LWP 5394)]
[Switching to Thread 1024 (LWP 5394)]

Breakpoint 1, main () at ex1.c:26
26        retcode = pthread_create(&th_a, NULL, process, (void *) "a");
(gdb) n
[New Thread 2049 (LWP 5395)]
[New Thread 1026 (LWP 5396)]
Starting process a
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa27     if
(retcode != 0) fprintf(stderr, "create a failed %d\n", retcode);
(gdb) info threads
  3 Thread 1026 (LWP 5396)  0x4011e584 in __libc_write () at __libc_write:-1
  2 Thread 2049 (LWP 5395)  0x401239f7 in __poll (fds=0x804b72c, nfds=1,
timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63
* 1 Thread 1024 (LWP 5394)  main () at ex1.c:27
(gdb)

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...

TIA,
Frank


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: multithreading and gdbserver
  2003-01-20 15:32 multithreading and gdbserver Frank van Eijkelenburg
@ 2003-01-20 16:36 ` Daniel Jacobowitz
  0 siblings, 0 replies; 2+ messages in thread
From: Daniel Jacobowitz @ 2003-01-20 16:36 UTC (permalink / raw)
  To: Frank van Eijkelenburg; +Cc: Gnu Debugger mailing list

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-01-20 16:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-20 15:32 multithreading and gdbserver Frank van Eijkelenburg
2003-01-20 16:36 ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox