* pthreads debug with gdbserver @ 2004-11-19 14:23 Vladimir Vorobyov 2004-11-19 14:42 ` Daniel Jacobowitz 2004-11-19 16:19 ` Andreas Schwab 0 siblings, 2 replies; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-19 14:23 UTC (permalink / raw) To: gdb Hi, Im using gbd 6.2 + gdbserver for m68k target and able to debug programs with it. But when I tried to debug application with pthreads I could not get correct threads information. During debbuging I receive a well known SIG32 but searching this mail list I did not find the solution for my problem. What I did: ****************************************************************************************** [root@Vlad]# ./m68k-linux-gdb GNU gdb 6.2 Copyright 2004 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 "--host=i686-pc-linux-gnu --target=m68k-linux". (gdb) file /tftpboot/Linux_BSP2/rootfsdir/bin/hello Reading symbols from /opt/Embedix/home/vladimir/project/rootfsdir/bin/hello...done. (gdb) maintenance info breakpoints Num Type Disp Enb Address What -1 longjmp resume keep n 0x00000000 (gdb) set solib-absolute-prefix /tftpboot/Linux_BSP2/rootfsdir/ (gdb) target remote 192.168.1.27:3000 Remote debugging using 192.168.1.27:3000 0x400020c0 in ?? () (gdb) maintenance info breakpoints Num Type Disp Enb Address What -1 longjmp resume keep n 0x00000000 -2 shlib events keep y 0x4000dd04 (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x400a8b2e in ?? () (gdb) maintenance info breakpoints Num Type Disp Enb Address What -1 longjmp resume keep n 0x00000000 -2 shlib events keep y 0x4000dd04 breakpoint already hit 3 times *************************************************************************************************** I see that shlib breakpoint is set and hit but gdb does not load the libraries. I can see in strace that it successfully loads ld.so. What should I look at? Next, what libthread_db.so is for? It was not included for compilation for m68k target and I added it manually but when I try to load all libraries manually using add-symbol-file, every library loads fine except libthread_db.so - gdbserver reports "gbd: error initializing thread_db library." If I type in gdb: info threads I always get only one thread. p.s. All libraries are not stripped. Any help would be very appreciated. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-19 14:23 pthreads debug with gdbserver Vladimir Vorobyov @ 2004-11-19 14:42 ` Daniel Jacobowitz 2004-11-19 15:59 ` Vladimir Vorobyov 2004-11-19 16:19 ` Andreas Schwab 1 sibling, 1 reply; 24+ messages in thread From: Daniel Jacobowitz @ 2004-11-19 14:42 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: gdb On Fri, Nov 19, 2004 at 12:33:22PM +0200, Vladimir Vorobyov wrote: > I see that shlib breakpoint is set and hit but gdb does not load the > libraries. I can see in strace that it successfully loads ld.so. What should > I look at? "info shared". Maybe strace GDB to see what it's opening and whether it fails to find any files. > Next, what libthread_db.so is for? It was not included for compilation for > m68k target and I added it manually but when I try to load all libraries > manually using add-symbol-file, every library loads fine except > libthread_db.so - gdbserver reports "gbd: error initializing thread_db > library." > If I type in gdb: > info threads > I always get only one thread. > p.s. All libraries are not stripped. libthread_db.so is necessary to debug threads. It has to be on your target (sounds like it is) and it has to be able to initialize; worry about this after you've figured out whether GDB loaded shared libraries, because it will not be able to initialize unless GDB can load an unstripped copy of libpthread.so. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-19 14:42 ` Daniel Jacobowitz @ 2004-11-19 15:59 ` Vladimir Vorobyov 2004-11-20 10:01 ` Daniel Jacobowitz 0 siblings, 1 reply; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-19 15:59 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb On Friday 19 November 2004 04:22 pm, Daniel Jacobowitz wrote: > On Fri, Nov 19, 2004 at 12:33:22PM +0200, Vladimir Vorobyov wrote: > > I see that shlib breakpoint is set and hit but gdb does not load the > > libraries. I can see in strace that it successfully loads ld.so. What > > should I look at? > "info shared". Maybe strace GDB to see what it's opening and whether > it fails to find any files. info shared reports: "No shared libraries loaded at this time". Straces shows that gdb opens only ld.so file. When adding printf to solibopen it also shows only ld.so. Who is responsible for loading shared libs ? What file/function/event? > > Next, what libthread_db.so is for? It was not included for compilation > > for m68k target and I added it manually but when I try to load all > > libraries manually using add-symbol-file, every library loads fine except > > libthread_db.so - gdbserver reports "gbd: error initializing thread_db > > library." > > If I type in gdb: > > info threads > > I always get only one thread. > > p.s. All libraries are not stripped. > > libthread_db.so is necessary to debug threads. It has to be on your > target (sounds like it is) and it has to be able to initialize; worry > about this after you've figured out whether GDB loaded shared > libraries, because it will not be able to initialize unless GDB can > load an unstripped copy of libpthread.so. Yes, the problem number one is that GDB does not auto loads shared libs. Is it not the same when I manually add-symbol-file lipthread.so? Can I do it to load shared libs ? When I do this I got "gbd: error initializing thread_db library." error on the target. When I add debug info to it, I see that error is "Incompatible versions of libpthread and libthread_db". But these two libs are from the same libc. It looks like this is my second problem. Or it depends on first one and may disappear when first problem is solved? Regards, Vladimir. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-19 15:59 ` Vladimir Vorobyov @ 2004-11-20 10:01 ` Daniel Jacobowitz 2004-11-20 16:42 ` Vladimir Vorobyov 2004-11-22 14:07 ` pthreads debug with gdbserver Vladimir Vorobyov 0 siblings, 2 replies; 24+ messages in thread From: Daniel Jacobowitz @ 2004-11-20 10:01 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: gdb On Fri, Nov 19, 2004 at 04:41:15PM +0200, Vladimir Vorobyov wrote: > On Friday 19 November 2004 04:22 pm, Daniel Jacobowitz wrote: > > On Fri, Nov 19, 2004 at 12:33:22PM +0200, Vladimir Vorobyov wrote: > > > I see that shlib breakpoint is set and hit but gdb does not load the > > > libraries. I can see in strace that it successfully loads ld.so. What > > > should I look at? > > > "info shared". Maybe strace GDB to see what it's opening and whether > > it fails to find any files. > > info shared reports: "No shared libraries loaded at this time". > Straces shows that gdb opens only ld.so file. > When adding printf to solibopen it also shows only ld.so. > Who is responsible for loading shared libs ? What file/function/event? This usually means that the ld.so GDB has opened is not -exactly- the same as the one on your target; and then it has set the solib event breakpoint at the wrong location, and it hasn't been hit. Take a look at solib-svr4.c if you want more details. > Yes, the problem number one is that GDB does not auto loads shared libs. > Is it not the same when I manually add-symbol-file lipthread.so? Can I do it > to load shared libs ? > When I do this I got "gbd: error initializing thread_db library." error on the > target. When I add debug info to it, I see that error is "Incompatible > versions of libpthread and libthread_db". But these two libs are from the > same libc. > It looks like this is my second problem. Or it depends on first one and may > disappear when first problem is solved? Are you sure you loaded the right copy? -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-20 10:01 ` Daniel Jacobowitz @ 2004-11-20 16:42 ` Vladimir Vorobyov 2004-11-20 16:57 ` Daniel Jacobowitz 2004-11-22 14:07 ` pthreads debug with gdbserver Vladimir Vorobyov 1 sibling, 1 reply; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-20 16:42 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb Thank for your inputs. I moved further - see below. > > info shared reports: "No shared libraries loaded at this time". > > Straces shows that gdb opens only ld.so file. > > When adding printf to solibopen it also shows only ld.so. > > Who is responsible for loading shared libs ? What file/function/event? > > This usually means that the ld.so GDB has opened is not -exactly- the > same as the one on your target; and then it has set the solib event > breakpoint at the wrong location, and it hasn't been hit. Take a look > at solib-svr4.c if you want more details. As I said in my first message the breakpoint is hit exactly 3 times. I found that current_sos in solib-svr4.c can not find any libraries. It was because first_link_map_member returned NULL. After this I found that SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are correct for me? ilp32?). I tried to follow those gdbach_data calls but it was too difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?). After this with every shlib breakpoint hit gdb loads appropriate shared lib BUT gdbserver reports "Target does not support breakpoints" 3 times for each library loaded. What does it mean ? I still receive SIG32, info threads still shows only one thread. "info shared" shows all libraries that are loaded and td_ta_new() call now returns successfully. > > Yes, the problem number one is that GDB does not auto loads shared libs. > > Is it not the same when I manually add-symbol-file lipthread.so? Can I do > > it to load shared libs ? > > When I do this I got "gbd: error initializing thread_db library." error > > on the target. When I add debug info to it, I see that error is > > "Incompatible versions of libpthread and libthread_db". But these two > > libs are from the same libc. > > It looks like this is my second problem. Or it depends on first one and > > may disappear when first problem is solved? > > Are you sure you loaded the right copy? Absolutely. Regards, Vladimir. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-20 16:42 ` Vladimir Vorobyov @ 2004-11-20 16:57 ` Daniel Jacobowitz 2004-11-20 17:13 ` Andreas Schwab ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Daniel Jacobowitz @ 2004-11-20 16:57 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: gdb, Andreas Schwab On Sat, Nov 20, 2004 at 02:27:13PM +0200, Vladimir Vorobyov wrote: > Thank for your inputs. I moved further - see below. > > > > info shared reports: "No shared libraries loaded at this time". > > > Straces shows that gdb opens only ld.so file. > > > When adding printf to solibopen it also shows only ld.so. > > > Who is responsible for loading shared libs ? What file/function/event? > > > > This usually means that the ld.so GDB has opened is not -exactly- the > > same as the one on your target; and then it has set the solib event > > breakpoint at the wrong location, and it hasn't been hit. Take a look > > at solib-svr4.c if you want more details. > > As I said in my first message the breakpoint is hit exactly 3 times. I found > that current_sos in solib-svr4.c can not find any libraries. It was because > first_link_map_member returned NULL. After this I found that > SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are correct > for me? ilp32?). I tried to follow those gdbach_data calls but it was too > difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to > SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?). > After this with every shlib breakpoint hit gdb loads appropriate shared lib > BUT gdbserver reports "Target does not support breakpoints" 3 times for each > library loaded. What does it mean ? > I still receive SIG32, info threads still shows only one thread. "info shared" > shows all libraries that are loaded and td_ta_new() call now returns > successfully. Take a look at the source code to gdbserver. Andreas, now I remember why I enabled thread_db support on a per-target basis - there are other support routines that have to be written. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-20 16:57 ` Daniel Jacobowitz @ 2004-11-20 17:13 ` Andreas Schwab 2004-11-20 17:38 ` Vladimir Vorobyov 2004-12-06 18:41 ` NPTL on ppc (was: pthreads debug with gdbserver) Linh Dang 2 siblings, 0 replies; 24+ messages in thread From: Andreas Schwab @ 2004-11-20 17:13 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: gdb Daniel Jacobowitz <drow@false.org> writes: > Take a look at the source code to gdbserver. Andreas, now I remember > why I enabled thread_db support on a per-target basis - there are other > support routines that have to be written. Yes, I have noticed that, too. I'm currently trying to get it working for m68k (plus support for PTRACE_GETREGS). Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-20 16:57 ` Daniel Jacobowitz 2004-11-20 17:13 ` Andreas Schwab @ 2004-11-20 17:38 ` Vladimir Vorobyov 2004-12-06 18:41 ` NPTL on ppc (was: pthreads debug with gdbserver) Linh Dang 2 siblings, 0 replies; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-20 17:38 UTC (permalink / raw) To: Daniel Jacobowitz, Andreas Schwab; +Cc: gdb, Andreas Schwab > > As I said in my first message the breakpoint is hit exactly 3 times. I found > > that current_sos in solib-svr4.c can not find any libraries. It was because > > first_link_map_member returned NULL. After this I found that > > SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are correct > > for me? ilp32?). I tried to follow those gdbach_data calls but it was too > > difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to > > SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?). > > After this with every shlib breakpoint hit gdb loads appropriate shared lib > > BUT gdbserver reports "Target does not support breakpoints" 3 times for each > > library loaded. What does it mean ? > > I still receive SIG32, info threads still shows only one thread. "info shared" > > shows all libraries that are loaded and td_ta_new() call now returns > > successfully. > > Take a look at the source code to gdbserver. Andreas, now I remember > why I enabled thread_db support on a per-target basis - there are other > support routines that have to be written. > Yes, I have noticed that, too. I'm currently trying to get it working for > m68k (plus support for PTRACE_GETREGS). What routines should I add? Also I've added set_solib_svr4_fetch_link_map_offsets (gdbarch, svr4_ilp32_fetch_link_map_offsets) to m68klinux-tdep.c. It fixed the problem with bad link_map_offsets. Regards, Vladimir. ^ permalink raw reply [flat|nested] 24+ messages in thread
* NPTL on ppc (was: pthreads debug with gdbserver) 2004-11-20 16:57 ` Daniel Jacobowitz 2004-11-20 17:13 ` Andreas Schwab 2004-11-20 17:38 ` Vladimir Vorobyov @ 2004-12-06 18:41 ` Linh Dang 2004-12-06 18:45 ` Daniel Jacobowitz 2 siblings, 1 reply; 24+ messages in thread From: Linh Dang @ 2004-12-06 18:41 UTC (permalink / raw) To: gdb Daniel Jacobowitz <drow@false.org> wrote: > > Take a look at the source code to gdbserver. Andreas, now I > remember why I enabled thread_db support on a per-target basis - > there are other support routines that have to be written. Hi Daniel and Andreas, Does gdbserver works with NPTL on ppc32? I use 6.3.50 and I keep getting on the target side: gdbserver 47.129.74.85:8888 p_greetings2 Process p_greetings2 created; pid = 288 Listening on port 8888 Remote debugging from host 47.129.74.85 error = 0 error = 0 Cannot find new threads: generic error error = 0 Cannot find new threads: generic error error = 0 Cannot find new threads: generic error and on the host side: target extended-remote 47.135.196.213:8888 Remote debugging using 47.135.196.213:8888 0x30011e28 in ?? () (gdb) b main Breakpoint 1 at 0x1000080c (gdb) info b Num Type Disp Enb Address What 1 breakpoint keep y 0x1000080c <main+28> (gdb) c Continuing. Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Breakpoint 1, 0x1000080c in main () (gdb) info shared From To Syms Read Shared Object Library 0x0ffd17e4 0x0ffdbd4c Yes /linux-tools-2.6/powerpc-linux/lib/libpthread.so.0 0x0fe9b060 0x0ff850a4 Yes /linux-tools-2.6/powerpc-linux/lib/libc.so.6 0x30001ee0 0x300155d0 Yes /linux-tools-2.6/powerpc-linux/lib/ld.so.1 (gdb) Thanx -- Linh Dang ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc (was: pthreads debug with gdbserver) 2004-12-06 18:41 ` NPTL on ppc (was: pthreads debug with gdbserver) Linh Dang @ 2004-12-06 18:45 ` Daniel Jacobowitz 2004-12-06 19:56 ` NPTL on ppc Linh Dang 0 siblings, 1 reply; 24+ messages in thread From: Daniel Jacobowitz @ 2004-12-06 18:45 UTC (permalink / raw) To: Linh Dang; +Cc: gdb On Mon, Dec 06, 2004 at 01:22:26PM -0500, Linh Dang wrote: > > Daniel Jacobowitz <drow@false.org> wrote: > > > > Take a look at the source code to gdbserver. Andreas, now I > > remember why I enabled thread_db support on a per-target basis - > > there are other support routines that have to be written. > > Hi Daniel and Andreas, > > Does gdbserver works with NPTL on ppc32? I use 6.3.50 and I keep > getting on the target side: 6.3.50 indicates some snapshot. It depends on when the snapshot was taken; can you give us the full version info? I believe it should work. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-06 18:45 ` Daniel Jacobowitz @ 2004-12-06 19:56 ` Linh Dang 2004-12-06 20:18 ` Daniel Jacobowitz 2004-12-06 22:04 ` Andreas Schwab 0 siblings, 2 replies; 24+ messages in thread From: Linh Dang @ 2004-12-06 19:56 UTC (permalink / raw) To: gdb (gdb) show version GNU gdb 6.3.50_20041027 Copyright 2004 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 "--host=i686-pc-linux-gnu --target=powerpc-linux". I got the same failure with any official version (6.2, 6.1.1, etc.) Regards -- Linh Dang ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-06 19:56 ` NPTL on ppc Linh Dang @ 2004-12-06 20:18 ` Daniel Jacobowitz 2004-12-06 22:41 ` Andreas Schwab 2004-12-06 23:20 ` Andreas Schwab 2004-12-06 22:04 ` Andreas Schwab 1 sibling, 2 replies; 24+ messages in thread From: Daniel Jacobowitz @ 2004-12-06 20:18 UTC (permalink / raw) To: Linh Dang; +Cc: gdb On Mon, Dec 06, 2004 at 02:56:19PM -0500, Linh Dang wrote: > > > (gdb) show version > GNU gdb 6.3.50_20041027 > Copyright 2004 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 "--host=i686-pc-linux-gnu --target=powerpc-linux". > > > I got the same failure with any official version (6.2, 6.1.1, etc.) Is your gdbserver also of that version? They should match. If so, I'm out of ideas; you will have to debug it yourself. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-06 20:18 ` Daniel Jacobowitz @ 2004-12-06 22:41 ` Andreas Schwab 2004-12-06 23:20 ` Andreas Schwab 1 sibling, 0 replies; 24+ messages in thread From: Andreas Schwab @ 2004-12-06 22:41 UTC (permalink / raw) To: Linh Dang; +Cc: gdb Daniel Jacobowitz <drow@false.org> writes: > If so, I'm out of ideas; you will have to debug it yourself. It may be a bug in glibc/libthread_db, td_ta_thr_iter is returning an error. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-06 20:18 ` Daniel Jacobowitz 2004-12-06 22:41 ` Andreas Schwab @ 2004-12-06 23:20 ` Andreas Schwab 2004-12-07 14:33 ` Linh Dang 1 sibling, 1 reply; 24+ messages in thread From: Andreas Schwab @ 2004-12-06 23:20 UTC (permalink / raw) To: Linh Dang; +Cc: gdb Daniel Jacobowitz <drow@false.org> writes: > If so, I'm out of ideas; you will have to debug it yourself. NPTL debugging requires a functional implementation of ps_lgetregs, but gdbserver on ppc does not implement it. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-06 23:20 ` Andreas Schwab @ 2004-12-07 14:33 ` Linh Dang 2004-12-07 14:56 ` Andreas Schwab 0 siblings, 1 reply; 24+ messages in thread From: Linh Dang @ 2004-12-07 14:33 UTC (permalink / raw) To: Andreas Schwab; +Cc: gdb Andreas Schwab <schwab@suse.de> wrote: > Daniel Jacobowitz <drow@false.org> writes: > >> If so, I'm out of ideas; you will have to debug it yourself. > > NPTL debugging requires a functional implementation of ps_lgetregs, > but gdbserver on ppc does not implement it. dummy question: ptrace(2) on linux-ppc doesn't support PTRACE_GETREGS, how does gdb get registers from the inferior process? (the native gdb works fine with NPTL, just gdbserver that has trouble.) Thanx -- Linh Dang ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-07 14:33 ` Linh Dang @ 2004-12-07 14:56 ` Andreas Schwab 0 siblings, 0 replies; 24+ messages in thread From: Andreas Schwab @ 2004-12-07 14:56 UTC (permalink / raw) To: Linh Dang; +Cc: gdb "Linh Dang" <linhd@nortelnetworks.com> writes: > ptrace(2) on linux-ppc doesn't support PTRACE_GETREGS, how does gdb > get registers from the inferior process? Using PTRACE_PEEKUSR and PTRACE_GETVRREGS and PTRACE_GETEVRREGS. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: NPTL on ppc 2004-12-06 19:56 ` NPTL on ppc Linh Dang 2004-12-06 20:18 ` Daniel Jacobowitz @ 2004-12-06 22:04 ` Andreas Schwab 1 sibling, 0 replies; 24+ messages in thread From: Andreas Schwab @ 2004-12-06 22:04 UTC (permalink / raw) To: Linh Dang; +Cc: gdb Linh Dang <linhd@nortelnetworks.com> writes: > (gdb) show version > GNU gdb 6.3.50_20041027 > Copyright 2004 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 "--host=i686-pc-linux-gnu --target=powerpc-linux". > > > I got the same failure with any official version (6.2, 6.1.1, etc.) I see the same problem with current CVS. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-20 10:01 ` Daniel Jacobowitz 2004-11-20 16:42 ` Vladimir Vorobyov @ 2004-11-22 14:07 ` Vladimir Vorobyov 2004-11-22 18:04 ` Daniel Jacobowitz 1 sibling, 1 reply; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-22 14:07 UTC (permalink / raw) To: Daniel Jacobowitz, Andreas Schwab; +Cc: gdb > > As I said in my first message the breakpoint is hit exactly 3 times. I found > > that current_sos in solib-svr4.c can not find any libraries. It was because > > first_link_map_member returned NULL. After this I found that > > SVR4_FETCH_LINK_MAP_OFFSETS did not return correct offsets (which are correct > > for me? ilp32?). I tried to follow those gdbach_data calls but it was too > > difficult. I just assigned svr4_ilp32_fetch_link_map_offsets to > > SVR4_FETCH_LINK_MAP_OFFSETS (how to do it correctly?). > > After this with every shlib breakpoint hit gdb loads appropriate shared lib > > BUT gdbserver reports "Target does not support breakpoints" 3 times for each > > library loaded. What does it mean ? > > I still receive SIG32, info threads still shows only one thread. "info shared" > > shows all libraries that are loaded and td_ta_new() call now returns > > successfully. > > Take a look at the source code to gdbserver. Andreas, now I remember > why I enabled thread_db support on a per-target basis - there are other > support routines that have to be written. > Yes, I have noticed that, too. I'm currently trying to get it working for > m68k (plus support for PTRACE_GETREGS). > What routines should I add? > Also I've added set_solib_svr4_fetch_link_map_offsets (gdbarch, > svr4_ilp32_fetch_link_map_offsets) to m68klinux-tdep.c. > It fixed the problem with bad link_map_offsets. I think I've added all missing routines and it ALMOST work. First, I have to specify 'set remotetimeout 60' otherwise gdb reports timeout error (Ignoring packet error, continuing...). - Is it normal ? Second, after I set any break point (e.g. break main) I cant use 'continue' command. Program stops after any instruction with SIGTRAP. When I force gdbserver to ignore 'stepping' variable, everything works fine. But Im sure it is wrong correction. Who is responsible for reseting stepping? And why we need it? Thanks in advance. Regards, Vladimir. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-22 14:07 ` pthreads debug with gdbserver Vladimir Vorobyov @ 2004-11-22 18:04 ` Daniel Jacobowitz 2004-11-23 19:33 ` Vladimir Vorobyov 0 siblings, 1 reply; 24+ messages in thread From: Daniel Jacobowitz @ 2004-11-22 18:04 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: Andreas Schwab, gdb On Mon, Nov 22, 2004 at 02:40:21PM +0200, Vladimir Vorobyov wrote: > I think I've added all missing routines and it ALMOST work. First, I > have to specify 'set remotetimeout 60' otherwise gdb reports timeout > error (Ignoring packet error, continuing...). > - Is it normal ? > Second, after I set any break point (e.g. break main) I cant use 'continue' > command. Program stops after any instruction with SIGTRAP. When I force > gdbserver to ignore 'stepping' variable, everything works fine. But Im sure > it is wrong correction. Who is responsible for reseting stepping? And why we > need it? Try CVS; Andreas has also just implemented m68k support. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-22 18:04 ` Daniel Jacobowitz @ 2004-11-23 19:33 ` Vladimir Vorobyov 0 siblings, 0 replies; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-23 19:33 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andreas Schwab, gdb On Monday 22 November 2004 04:06 pm, Daniel Jacobowitz wrote: > On Mon, Nov 22, 2004 at 02:40:21PM +0200, Vladimir Vorobyov wrote: > > I think I've added all missing routines and it ALMOST work. First, I > > have to specify 'set remotetimeout 60' otherwise gdb reports timeout > > error (Ignoring packet error, continuing...). > > - Is it normal ? > > Second, after I set any break point (e.g. break main) I cant use > > 'continue' command. Program stops after any instruction with SIGTRAP. > > When I force gdbserver to ignore 'stepping' variable, everything works > > fine. But Im sure it is wrong correction. Who is responsible for reseting > > stepping? And why we need it? > > Try CVS; Andreas has also just implemented m68k support. I've downloaded the CVS version and have some questions: 1) When I try to debug following example: ************************************************************************************* 3 #define NUM_THREADS 5 4 5 void *thread_function(void *arg) 6 { 7 printf("Hello World from %d!\n", arg); 8 sleep(10); 9 printf("Exited %d!\n", arg); 10 pthread_exit(NULL); 11 } 12 13 int main (int argc, char *argv[]) 14 { 15 pthread_t threads[NUM_THREADS]; 16 int i; 17 18 for (i = 0; i < NUM_THREADS; i++) 19 { 20 pthread_create(&threads[i], NULL, thread_function, (void *)i); 21 printf("Thread %d created.\n", i); 22 } 23 for (i = 0; i < NUM_THREADS; i++) 24 pthread_join(threads[i], NULL); 25 26 printf("finish!\n"); 27 return (0); 28 } ****************************************************************************************** I put first break point to line 23. When program stops, 'info threads' shows: (gdb) info threads 7 Thread 81926 0x40126f56 in nanosleep () from /tftpboot/rootfsdir/lib/libc.so.6 6 Thread 65541 0x40126f56 in nanosleep () from /tftpboot/rootfsdir/lib/libc.so.6 5 Thread 49156 0x40126f56 in nanosleep () from /tftpboot/rootfsdir/lib/libc.so.6 4 Thread 32771 0x40126f56 in nanosleep () from /tftpboot/rootfsdir/lib/libc.so.6 3 Thread 16386 0x40126f56 in nanosleep () from /tftpboot/rootfsdir/lib/libc.so.6 2 Thread 32769 0x40150a0e in loser_poll () from /tftpboot/rootfsdir/lib/libc.so.6 * 1 Thread 16384 main (argc=1, argv=0xbffffe04) at hello.c:23 Looks perfectly for me. After this if I set "break 9 thread 3" and "continue", program stops on correct line but I can't 'step' it: (gdb) c Continuing. [Switching to Thread 16386] Breakpoint 4, thread_function (arg=0x0) at hello.c:9 9 printf("Exited from %d!\n", arg); (gdb) step Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 32771] 0x80000540 in thread_function (arg=0x1) at hello.c:9 9 printf("Exited from %d!\n", arg); (gdb) c Continuing. Program received signal SIGILL, Illegal instruction. 0x80000540 in thread_function (arg=0x1) at hello.c:9 9 printf("Exited from %d!\n", arg); (gdb) x /20i $pc 0x80000540 <thread_function+36>: 010 0x80000542 <thread_function+38>: pea 0x800006d4 <_IO_stdin_used+26> 0x80000548 <thread_function+44>: bsrl 0x80000414 <printf> 0x8000054e <thread_function+50>: addql #8,%sp 0x80000550 <thread_function+52>: clrl %sp@- 0x80000552 <thread_function+54>: bsrl 0x80000444 <pthread_exit> 0x80000558 <thread_function+60>: nop 0x8000055a <main>: linkw %fp,#-24 0x8000055e <main+4>: clrl %fp@(-24) ...... Andreas, do you have this problem on your side? 2) I still need 'set remotetimeout 30' because otherwise I get error "Ignoring packet error, continuing...". What can gdbserver do for 30 seconds? Sorry for the long post. Could you recommend anything? Regards, Vladimir. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-19 14:23 pthreads debug with gdbserver Vladimir Vorobyov 2004-11-19 14:42 ` Daniel Jacobowitz @ 2004-11-19 16:19 ` Andreas Schwab 2004-11-19 17:30 ` Vladimir Vorobyov 1 sibling, 1 reply; 24+ messages in thread From: Andreas Schwab @ 2004-11-19 16:19 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: gdb Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes: > Next, what libthread_db.so is for? It was not included for compilation for > m68k target and I added it manually What do you mean with "not included for compilation"? Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-19 16:19 ` Andreas Schwab @ 2004-11-19 17:30 ` Vladimir Vorobyov 2004-11-20 1:31 ` Andreas Schwab 0 siblings, 1 reply; 24+ messages in thread From: Vladimir Vorobyov @ 2004-11-19 17:30 UTC (permalink / raw) To: Andreas Schwab; +Cc: gdb On Friday 19 November 2004 05:53 pm, Andreas Schwab wrote: > Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes: > > Next, what libthread_db.so is for? It was not included for compilation > > for m68k target and I added it manually > > What do you mean with "not included for compilation"? > > Andreas. Sorry for my English. I mean that this file (thread_db.c) was not compiled when I was building gdbserver for m68k-linux-gcc target, and gdbserver was not linked with libthread_db. I've added "srv_linux_thread_db=yes" to "m68*-*-linux*" section of configure.srv file. Is it correct? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-19 17:30 ` Vladimir Vorobyov @ 2004-11-20 1:31 ` Andreas Schwab 2004-11-20 1:32 ` Daniel Jacobowitz 0 siblings, 1 reply; 24+ messages in thread From: Andreas Schwab @ 2004-11-20 1:31 UTC (permalink / raw) To: Vladimir Vorobyov; +Cc: gdb Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes: > I've added "srv_linux_thread_db=yes" to "m68*-*-linux*" section of > configure.srv file. Is it correct? I think so. Actually I don't understand why it is actually not enabled for _all_ linux targets, since it's a generic part of glibc. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: pthreads debug with gdbserver 2004-11-20 1:31 ` Andreas Schwab @ 2004-11-20 1:32 ` Daniel Jacobowitz 0 siblings, 0 replies; 24+ messages in thread From: Daniel Jacobowitz @ 2004-11-20 1:32 UTC (permalink / raw) To: Andreas Schwab; +Cc: Vladimir Vorobyov, gdb On Fri, Nov 19, 2004 at 06:05:04PM +0100, Andreas Schwab wrote: > Vladimir Vorobyov <vladimir.vorobyov@iss.org.ua> writes: > > > I've added "srv_linux_thread_db=yes" to "m68*-*-linux*" section of > > configure.srv file. Is it correct? > > I think so. Actually I don't understand why it is actually not enabled > for _all_ linux targets, since it's a generic part of glibc. 'cuz it never occured to me to do it that way. If you would like to fix this, please go ahead. -- Daniel Jacobowitz ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2004-12-07 14:56 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-11-19 14:23 pthreads debug with gdbserver Vladimir Vorobyov 2004-11-19 14:42 ` Daniel Jacobowitz 2004-11-19 15:59 ` Vladimir Vorobyov 2004-11-20 10:01 ` Daniel Jacobowitz 2004-11-20 16:42 ` Vladimir Vorobyov 2004-11-20 16:57 ` Daniel Jacobowitz 2004-11-20 17:13 ` Andreas Schwab 2004-11-20 17:38 ` Vladimir Vorobyov 2004-12-06 18:41 ` NPTL on ppc (was: pthreads debug with gdbserver) Linh Dang 2004-12-06 18:45 ` Daniel Jacobowitz 2004-12-06 19:56 ` NPTL on ppc Linh Dang 2004-12-06 20:18 ` Daniel Jacobowitz 2004-12-06 22:41 ` Andreas Schwab 2004-12-06 23:20 ` Andreas Schwab 2004-12-07 14:33 ` Linh Dang 2004-12-07 14:56 ` Andreas Schwab 2004-12-06 22:04 ` Andreas Schwab 2004-11-22 14:07 ` pthreads debug with gdbserver Vladimir Vorobyov 2004-11-22 18:04 ` Daniel Jacobowitz 2004-11-23 19:33 ` Vladimir Vorobyov 2004-11-19 16:19 ` Andreas Schwab 2004-11-19 17:30 ` Vladimir Vorobyov 2004-11-20 1:31 ` Andreas Schwab 2004-11-20 1:32 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).