* Q: GDB - Threads @ 2009-05-26 16:02 Vellemans, Noel 2009-05-26 22:08 ` Hui Zhu 0 siblings, 1 reply; 11+ messages in thread From: Vellemans, Noel @ 2009-05-26 16:02 UTC (permalink / raw) To: gdb Hi, Somebody who can point me to a document (URL) that contains some info about GDB-(server)debugging with threads ? I'm having problems debugging multithread applications (compiled for ARM). Ref to : http://sourceware.org/ml/gdb/2009-05/msg00137.html GDB-6.8 (for ARM). /toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb --v GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux-uclibc". Kind Regards, Noel. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-05-26 16:02 Q: GDB - Threads Vellemans, Noel @ 2009-05-26 22:08 ` Hui Zhu 2009-06-02 15:27 ` Vellemans, Noel 0 siblings, 1 reply; 11+ messages in thread From: Hui Zhu @ 2009-05-26 22:08 UTC (permalink / raw) To: Vellemans, Noel; +Cc: gdb http://sourceware.org/gdb/current/onlinedocs/gdb_5.html#SEC28 http://sourceware.org/gdb/wiki/FAQ GDB does not see any threads besides the one in which crash occurred; or SIGTRAP kills my program when I set a breakpoint. * This frequently happen on Linux, especially on embedded targets. There are two common causes: o you are using glibc, and you have stripped libpthread.so.0 o mismatch between libpthread.so.0 and libthread_db.so.1 GDB itself does not know how to decode "thread control blocks" maintained by glibc and considered to be glibc private implementation detail. It uses libhread_db.so.1 (part of glibc) to help it do so. Therefore, libthread_db.so.1 and libpthread.so.0 must match in version and compilation flags. In addition, libthread_db.so.1 requires certain non-global symbols to be present in libpthread.so.0. Solution: use strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0. On Wed, May 27, 2009 at 00:02, Vellemans, Noel <Noel.Vellemans@visionbms.com> wrote: > > Hi, > > Somebody who can point me to a document (URL) that contains some info > about GDB-(server)debugging with threads ? > > I'm having problems debugging multithread applications (compiled for > ARM). > > > Ref to : http://sourceware.org/ml/gdb/2009-05/msg00137.html > > > > GDB-6.8 (for ARM). > > /toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb --v > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "--host=i386-pc-linux-gnu > --target=arm-linux-uclibc". > > > > > > > > > Kind Regards, > Noel. > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Q: GDB - Threads 2009-05-26 22:08 ` Hui Zhu @ 2009-06-02 15:27 ` Vellemans, Noel 2009-06-02 16:41 ` Paul Pluzhnikov 0 siblings, 1 reply; 11+ messages in thread From: Vellemans, Noel @ 2009-06-02 15:27 UTC (permalink / raw) To: gdb Hi, still strugling to DEBUG threads... I ' got a hint from someone that told me. A) I should check if my libpthread.so.0 if it is not stripped. And it isn't .. arm-linux-uclibc-nm libpthread-0.9.30.1.so 00012cf4 a _DYNAMIC 00012dbc a _GLOBAL_OFFSET_TABLE_ w _Jv_RegisterClasses 00012ce4 d __CTOR_END__ 00012cdc d __CTOR_LIST__ 00012cec d __DTOR_END__ 00012ce8 d __DTOR_LIST__ 0000a25c r __EH_FRAME_BEGIN__ ...... < removed some stuff here >> B) that there should be a mismatch between libthread.so.0 and libthread_db.so.1 Both libs have been build on the same system.. (buildroot).. Even started from scratch.... 88 -rw-r--r-- 1 noel noel 82178 2009-06-02 16:23 libpthread-0.9.30.1.so 0 lrwxrwxrwx 1 noel noel 22 2009-06-02 16:23 libpthread.so.0 -> libpthread-0.9.30.1.so 16 -rw-r--r-- 1 noel noel 13171 2009-06-02 16:23 libthread_db-0.9.30.1.so 0 lrwxrwxrwx 1 noel noel 24 2009-06-02 16:23 libthread_db.so.1 -> libthread_db-0.9.30.1.so Still not able to debug a MT-application :-( Anyone that can help me 'little' further ?? Ref to : http://sourceware.org/ml/gdb/2009-05/msg00137.html Kind regards Noel. -----Original Message----- From: Hui Zhu [mailto:teawater@gmail.com] Sent: 27May09 00:08 To: Vellemans, Noel Cc: gdb@sourceware.org Subject: Re: Q: GDB - Threads http://sourceware.org/gdb/current/onlinedocs/gdb_5.html#SEC28 http://sourceware.org/gdb/wiki/FAQ GDB does not see any threads besides the one in which crash occurred; or SIGTRAP kills my program when I set a breakpoint. * This frequently happen on Linux, especially on embedded targets. There are two common causes: o you are using glibc, and you have stripped libpthread.so.0 o mismatch between libpthread.so.0 and libthread_db.so.1 GDB itself does not know how to decode "thread control blocks" maintained by glibc and considered to be glibc private implementation detail. It uses libhread_db.so.1 (part of glibc) to help it do so. Therefore, libthread_db.so.1 and libpthread.so.0 must match in version and compilation flags. In addition, libthread_db.so.1 requires certain non-global symbols to be present in libpthread.so.0. Solution: use strip --strip-debug libpthread.so.0 instead of strip libpthread.so.0. On Wed, May 27, 2009 at 00:02, Vellemans, Noel <Noel.Vellemans@visionbms.com> wrote: > > Hi, > > Somebody who can point me to a document (URL) that contains some info > about GDB-(server)debugging with threads ? > > I'm having problems debugging multithread applications (compiled for > ARM). > > > Ref to : http://sourceware.org/ml/gdb/2009-05/msg00137.html > > > > GDB-6.8 (for ARM). > > /toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb --v GNU gdb 6.8 Copyright > (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" > and "show warranty" for details. > This GDB was configured as "--host=i386-pc-linux-gnu > --target=arm-linux-uclibc". > > > > > > > > > Kind Regards, > Noel. > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-06-02 15:27 ` Vellemans, Noel @ 2009-06-02 16:41 ` Paul Pluzhnikov 2009-06-02 18:17 ` Daniel Jacobowitz 0 siblings, 1 reply; 11+ messages in thread From: Paul Pluzhnikov @ 2009-06-02 16:41 UTC (permalink / raw) To: Vellemans, Noel; +Cc: gdb On Tue, Jun 2, 2009 at 8:27 AM, Vellemans, Noel <Noel.Vellemans@visionbms.com> wrote: > Still not able to debug a MT-application :-( > Anyone that can help me 'little' further ?? There is (I think) a very high probability that your GDB did not load correct libthread_db. > Both libs have been build on the same system.. (buildroot).. > Even started from scratch.... > 88 -rw-r--r-- 1 noel noel 82178 2009-06-02 16:23 libpthread-0.9.30.1.so > 16 -rw-r--r-- 1 noel noel 13171 2009-06-02 16:23 libthread_db-0.9.30.1.so The identical time stamp implies that these were both installed at the same time, which means they are both built for *target*. But you need an identical libthread_db built for *host*. This is because GDB (on host) will try to dlopen() libthread_db (which helps it debug *target* libpthread). Once you build correct libthread_db, you'll likely need to adjust LD_LIBRARY_PATH for GDB to actually find it at runtime. To see which (if any) libthread_db GDB is loading now do this: in a separate window execute 'grep libthread_db /proc/<pid-of-gdb>/maps' Cheers, -- Paul Pluzhnikov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-06-02 16:41 ` Paul Pluzhnikov @ 2009-06-02 18:17 ` Daniel Jacobowitz 2009-06-02 18:34 ` Paul Pluzhnikov 2009-06-03 9:26 ` Vellemans, Noel 0 siblings, 2 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2009-06-02 18:17 UTC (permalink / raw) To: Paul Pluzhnikov; +Cc: Vellemans, Noel, gdb On Tue, Jun 02, 2009 at 09:41:19AM -0700, Paul Pluzhnikov wrote: > > Both libs have been build on the same system.. (buildroot).. > > Even started from scratch.... > > 88 -rw-r--r-- 1 noel noel 82178 2009-06-02 16:23 libpthread-0.9.30.1.so > > 16 -rw-r--r-- 1 noel noel 13171 2009-06-02 16:23 libthread_db-0.9.30.1.so > > The identical time stamp implies that these were both installed at the > same time, which means they are both built for *target*. > > But you need an identical libthread_db built for *host*. > > This is because GDB (on host) will try to dlopen() libthread_db (which > helps it debug *target* libpthread). I'm not sure what you mean. GDB never uses libthread_db on the host if it is debugging a remote target. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-06-02 18:17 ` Daniel Jacobowitz @ 2009-06-02 18:34 ` Paul Pluzhnikov 2009-06-02 19:34 ` Daniel Jacobowitz 2009-06-02 19:42 ` Paul Pluzhnikov 2009-06-03 9:26 ` Vellemans, Noel 1 sibling, 2 replies; 11+ messages in thread From: Paul Pluzhnikov @ 2009-06-02 18:34 UTC (permalink / raw) To: Paul Pluzhnikov, Vellemans, Noel, gdb On Tue, Jun 2, 2009 at 11:17 AM, Daniel Jacobowitz <drow@false.org> wrote: > GDB never uses libthread_db on the host > if it is debugging a remote target. Oops. Sorry, my mistake. I guess then OP needs to verify that GDB is loading symbols from expected libpthread ("set verbose on" should show that), and that gdbserver on target is loading expected libthread_db ("ldd gdbserver" on target should show that). -- Paul Pluzhnikov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-06-02 18:34 ` Paul Pluzhnikov @ 2009-06-02 19:34 ` Daniel Jacobowitz 2009-06-03 15:21 ` Vellemans, Noel 2009-06-02 19:42 ` Paul Pluzhnikov 1 sibling, 1 reply; 11+ messages in thread From: Daniel Jacobowitz @ 2009-06-02 19:34 UTC (permalink / raw) To: Paul Pluzhnikov; +Cc: Vellemans, Noel, gdb On Tue, Jun 02, 2009 at 11:34:40AM -0700, Paul Pluzhnikov wrote: > On Tue, Jun 2, 2009 at 11:17 AM, Daniel Jacobowitz <drow@false.org> wrote: > > > GDB never uses libthread_db on the host > > if it is debugging a remote target. > > Oops. Sorry, my mistake. > > I guess then OP needs to verify that GDB is loading symbols from expected > libpthread ("set verbose on" should show that), and that gdbserver on target > is loading expected libthread_db ("ldd gdbserver" on target should show > that). Right. I don't remember if gdbserver's debug output helps with this or not. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Q: GDB - Threads 2009-06-02 19:34 ` Daniel Jacobowitz @ 2009-06-03 15:21 ` Vellemans, Noel 0 siblings, 0 replies; 11+ messages in thread From: Vellemans, Noel @ 2009-06-03 15:21 UTC (permalink / raw) To: gdb I'm here again... Tried all suggestions... but still not working. I guess I'm missing something but ..... What? Some ideas or hints, or some places ..where to find more info ? I've been digging in the GDB-manual and mailing list for some time now... :-( :-( I'll try to give a small resume of what I'm trying to do. *HOST : PC (ubuntu 9.04) *TARGET : ARM (at91sam9g20) *Buildsystem: buildroot 06/2009 - uclibc-0.9.30.1, gdb 6.8,gcc-4.3.3 *Striping : TURNED OFF. (for all files, this also means libs) *Test-Application : a simpe applciation that uses PTHREAD's!! *GDB: GDB / Gdbserver 6.8 for ARM (all is built for arm-linux-uclibc- ) When the application is run in 'remote-'gdb the application 'HANGS' as soon as the second thread is created. (target : gdbserver *:9000 ./threading) (host : gdb - over TCP/IP -> target ip-address port 9000) >>> target console log <<< # gdbserver *:9000 ./threading Process ./threading created; pid = 905 Listening on port 9000 Remote debugging from host 150.158.205.4 Creating thread 0 0: Hello World! 0 Creating thread 1 0: Hello World! 1 --->> and now .. the target is 'HANGING' <<--------- >> a normal run on the target ARM -- gives me the expected output << When the Test-application runs STAND-ALONE on the target (normal behavoir... As expected ;-)) ./threading Creating thread 0 0: Hello World! 0 Creating thread 1 1: Hello World! 0 Creating thread 2 2: Hello World! 0 Creating thread 3 3: Hello World! 0 Creating thread 4 4: Hello World! 0 Sleeping/printing in main ..... printing in main 0 0: Hello World! 1 1: Hello World! 1 2: Hello World! 1 << some things.. Are removed here >> Hello World! 19 4: Hello World! 19 printing in main 19 printing in main 20 printing in main 21 printing in main 22 printing in main 23 printing in main 24 printing in main 25 printing in main 26 printing in main 27 printing in main 28 printing in main 29 Sleeping in main ..... DONE .. What I do not understand is the following: Most people (that have responded, again THANKS for all responses, and sorry I'll keep on bothering you all, but I'm just trying to get my DEBUGGING problem solved..) point me to the fact that my libs (especially libthread_db) would be a wrong version.. But here it comes ... I can't see/understand why I would need libthread_db .. I'm using pthreads ! In fact the only thing I try (at this time) is to step in the 'main' of the program, even not in a 'p'thread. << please have a look at this GDB-CONSOLE-LOG >> /buildhome/20090601/buildroot/toolchain_build_arm/gdbhost-6.8/gdb$ ./gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i386-pc-linux-gnu --target=arm-linux-uclibc". Setting up the environment for debugging gdb. Setting up the environment for debugging gdb - DONE . Breakpoint 1 at 0x8784: file sources/main.c, line 46. (NOEL2-gdb) run Starting program: /tmp/threading [New Thread 906] [Switching to Thread 906] Stopped due to shared library event (NOEL2-gdb) c Continuing. Stopped due to shared library event (NOEL2-gdb) info shared li From To Syms Read Shared Object Library 0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0 0x40011cc0 0x4001820c Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibpthread.so.0 0x40029ca0 0x40030ec4 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibgcc_s.so.1 0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0 (NOEL2-gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00008784 in main at sources/main.c:46 (NOEL2-gdb) l 37 } 38 pthread_exit(NULL); 39 } 40 41 int main() 42 { 43 pthread_t threads[NUM_THREADS]; 44 int rc, t; 45 for(t=0;t<NUM_THREADS;t++){ 46 printf("Creating thread %d\r\n", t); (NOEL2-gdb) l 47 rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t); 48 if (rc){ 49 printf("ERROR; return code from pthread_create() is %d\r\n", rc); 50 exit(-1); 51 } 52 } 53 54 printf("Sleeping/printing in main ..... \r\n"); 55 { 56 int n; (NOEL2-gdb) b main.c:48 Breakpoint 2 at 0x87f8: file sources/main.c, line 48. (NOEL2-gdb) c Continuing. Breakpoint 1, main () at sources/main.c:46 46 printf("Creating thread %d\r\n", t); (NOEL2-gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00008784 in main at sources/main.c:46 breakpoint already hit 1 time 2 breakpoint keep y 0x000087f8 in main at sources/main.c:48 (NOEL2-gdb) info shared li From To Syms Read Shared Object Library 0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0 0x40011cc0 0x4001820c Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibpthread.so.0 0x40029ca0 0x40030ec4 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibgcc_s.so.1 0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0 (NOEL2-gdb) c Continuing. Breakpoint 2, main () at sources/main.c:48 48 if (rc){ (NOEL2-gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00008784 in main at sources/main.c:46 breakpoint already hit 1 time 2 breakpoint keep y 0x000087f8 in main at sources/main.c:48 breakpoint already hit 1 time (NOEL2-gdb) c Continuing. << HANGING >> I would expect the GDB-debugger to stop at main.c:48 (the break point is still there ...) but it doesn't. (and the programs HANGS forever)! The Target Console output I get is : Remote debugging from host 150.158.205.4 Process /tmp/threading created; pid = 906 Creating thread 0 0: Hello World! 0 Creating thread 1 0: Hello World! 1 << HANGING >> Kind regards, Noel. -----Original Message----- From: Daniel Jacobowitz [mailto:drow@false.org] Sent: 2Jun09 21:34 To: Paul Pluzhnikov Cc: Vellemans, Noel; gdb@sourceware.org Subject: Re: Q: GDB - Threads On Tue, Jun 02, 2009 at 11:34:40AM -0700, Paul Pluzhnikov wrote: > On Tue, Jun 2, 2009 at 11:17 AM, Daniel Jacobowitz <drow@false.org> wrote: > > > GDB never uses libthread_db on the host if it is debugging a remote > > target. > > Oops. Sorry, my mistake. > > I guess then OP needs to verify that GDB is loading symbols from > expected libpthread ("set verbose on" should show that), and that > gdbserver on target is loading expected libthread_db ("ldd gdbserver" > on target should show that). Right. I don't remember if gdbserver's debug output helps with this or not. -- Daniel Jacobowitz CodeSourcery ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-06-02 18:34 ` Paul Pluzhnikov 2009-06-02 19:34 ` Daniel Jacobowitz @ 2009-06-02 19:42 ` Paul Pluzhnikov 2009-06-03 3:17 ` Hui Zhu 1 sibling, 1 reply; 11+ messages in thread From: Paul Pluzhnikov @ 2009-06-02 19:42 UTC (permalink / raw) To: Paul Pluzhnikov, Vellemans, Noel, gdb On Tue, Jun 2, 2009 at 11:34 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote: > I guess then OP needs to verify that GDB is loading symbols from expected > libpthread ("set verbose on" should show that), and that gdbserver on target > is loading expected libthread_db ("ldd gdbserver" on target should show > that). Oh, and one very common mistake is to strip libpthread before it is uploaded to target. Make sure libpthread *on target* has not been stripped. In particular, it should have some local *_version symbol. Cheers, -- Paul Pluzhnikov ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Q: GDB - Threads 2009-06-02 19:42 ` Paul Pluzhnikov @ 2009-06-03 3:17 ` Hui Zhu 0 siblings, 0 replies; 11+ messages in thread From: Hui Zhu @ 2009-06-03 3:17 UTC (permalink / raw) To: Vellemans, Noel; +Cc: gdb, Paul Pluzhnikov On Wed, Jun 3, 2009 at 03:42, Paul Pluzhnikov <ppluzhnikov@google.com> wrote: > On Tue, Jun 2, 2009 at 11:34 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote: > >> I guess then OP needs to verify that GDB is loading symbols from expected >> libpthread ("set verbose on" should show that), and that gdbserver on target >> is loading expected libthread_db ("ldd gdbserver" on target should show >> that). > > Oh, and one very common mistake is to strip libpthread before it is uploaded > to target. Make sure libpthread *on target* has not been stripped. In > particular, it should have some local *_version symbol. > I remember in remote debug, libpthread striped or not is not very important. Noel, you are use remote debug right? If so, I suggest: 1. Make sure you gdbserver in target link with libthread_db is OK. You can check it with ldd. 2. Make sure you gdb in host use right lib. Sometime, the host and target use different lib. If so, you need copy the lib in target to host, and then you can use command "set solib-search-path" or "set sysroot" in gdb to let gdb load right lib. And you need make sure libpthread that gdb load (in host) is not striped. Thanks, Hui ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Q: GDB - Threads 2009-06-02 18:17 ` Daniel Jacobowitz 2009-06-02 18:34 ` Paul Pluzhnikov @ 2009-06-03 9:26 ` Vellemans, Noel 1 sibling, 0 replies; 11+ messages in thread From: Vellemans, Noel @ 2009-06-03 9:26 UTC (permalink / raw) To: gdb Hi, First of all I want to thank everyone dor the responses so far.... Here it goes..... I want to mention that I have used NO STRIPING, i.o.w strip is turned off for all lib files (in fact for all files on the target, no striping is used !) On Tue, Jun 02, 2009 at 09:41:19AM -0700, Paul Pluzhnikov wrote: > > > Both libs have been build on the same system.. (buildroot).. > > > Even started from scratch.... > > > 88 -rw-r--r-- 1 noel noel 82178 2009-06-02 16:23 > > > libpthread-0.9.30.1.so > > > 16 -rw-r--r-- 1 noel noel 13171 2009-06-02 16:23 > > > libthread_db-0.9.30.1.so > > > > The identical time stamp implies that these were both installed at the > > same time, which means they are both built for *target*. > > > > But you need an identical libthread_db built for *host*. > > Ohhh , I think this is where it goes wrong, I was not aware of this. NOTE: for the HOST !! ldd libthread_db-1.0.so checking sub-depends for 'libc.so.6' libc.so.6 => libc.so.6 (0x00000000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000) for the TARGET ldd libthread_db-0.9.30.1.so checking sub-depends for 'libc.so.0' libc.so.0 => libc.so.0 (0x00000000) /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) SO this is WRONG...!!! The question I now have is: My target is an ARM system (at91sam9g20), my host is a PC. What is the CORRECT way of getting this libfile (and dependencies) the same 'versions' on both systems! I assume taking a 'copy' of the *target*/lib/libthread_db to *host*/lib/libthread_db will not work (because the target is an ARM and the host is a PC). Some more questions remarks... (please ref to gdb verbose console log.. you might find something 'usable' in it.. ) I have set the "gdb-set solib-search-path /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib:/ target/lib" but gdb always find's the 'wrong ones' (because the are in *HOST*/lib...) After verbose mode I got this output in the gdbconsole. warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?) &"warning: .dynamic section for \"/lib/libpthread.so.0\" is not at the expected address (wrong library or version mismatch?)\n" &"warning: .dynamic section for \"/lib/libgcc_s.so.1\" is not at the expected address (wrong library or version mismatch?)\n" ~"Stopped due to shared library event\n" Stopped due to shared library event 24*stopped,thread-id="1" (gdb) 25 info sharedlibrary &"info sharedlibrary\n" ~"From To Syms Read Shared Object Library\n" ~"0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0\n" ~"0x400121b0 0x4001d628 Yes /lib/libpthread.so.0\n" ======> BAD ONE ! <======= ~"0x40029cb0 0x40032ee8 Yes /lib/libgcc_s.so.1\n" ======>IS THIS IS A BAD ONE ???? <======= ~"0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0\n" 25^done At this time (for testing) I have deleted the "wrong" libfiles on my host, to make sure GDB finds the correct ones.:-)) And now I have this output... Stopped due to shared library event 204*stopped,thread-id="1" (gdb) 205 info sharedlibrary &"info sharedlibrary\n" ~"From To Syms Read Shared Object Library\n" ~"0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0\n" ~"0x40011cc0 0x4001820c Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibpthread.so.0\n" ==>> OK <== ~"0x40029ca0 0x40030ec4 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibgcc_s.so.1\n" ==>> ?? BETTER ?? <== ~"0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0\n" 205^done Which seems to be better ... I guess :-), but how do I fix this the normal way (without deleting) ? I have included the gdb console log , you guy's might see anything in it I'm not aware Kind regards NOEL. <<< GBD verbose conlose log... >>> 1-gdb-set confirm off 1^done (gdb) 2-gdb-set width 0 2^done (gdb) 3-gdb-set height 0 3^done (gdb) 4-interpreter-exec console echo 4^done (gdb) 5-gdb-show prompt 5^done,value="(gdb) " (gdb) 6-gdb-set auto-solib-add on 6^done (gdb) 7-gdb-set stop-on-solib-events 0 7^done (gdb) 8-gdb-set stop-on-solib-events 1 8^done (gdb) 9-gdb-show solib-search-path 9^done,value="" (gdb) 10-gdb-set solib-search-path /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib:/ target/lib 10^done (gdb) 11-target-select remote 150.158.204.147:9000 ~"[New Thread 912]\n" [New Thread 912] 11^connected,thread-id="1",frame={addr="0x40000930",func="_start",args=[ ],from="/buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/ro ot/lib/ld-uClibc.so.0"} (gdb) 12-environment-cd /buildhome/DU7PE/software/threading 12^done (gdb) 13-environment-directory /buildhome/DU7PE/software/threading /buildhome/DU7PE/software/threading/sources 13^done,source-path="/buildhome/DU7PE/software/threading:/buildhome/DU7P E/software/threading/sources:$cdir:$cwd" (gdb) 14 info threads &"info threads\n" ~"* 1 Thread 912 0x40000930 in _start () from /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0\n" 14^done (gdb) 15-data-list-register-names 15^done,register-names=["r0","r1","r2","r3","r4","r5","r6","r7","r8","r9 ","r10","r11","r12","sp","lr","pc","f0","f1","f2","f3","f4","f5","f6","f 7","fps","cpsr","","","","","","","","","","","","","","","","","","","" ,"","","","","","","","","","","","",""] (gdb) 16-stack-info-depth 16^done,depth="2" (gdb) 17-stack-list-frames 0 2 17^done,stack=[frame={level="0",addr="0x40000930",func="_start",from="/b uildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/ld- uClibc.so.0"},frame={level="1",addr="0x00000000",func="??"}] (gdb) 18-break-insert -t main During symbol reading, DW_AT_name missing from DW_TAG_base_type. &"During symbol reading, DW_AT_name missing from DW_TAG_base_type.\n" 18^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr=" 0x00008784",func="main",file="sources/main.c",fullname="/buildhome/DU7PE /software/threading/sources/main.c",line="46",times="0"} (gdb) 19-exec-continue 19^running (gdb) ~"Stopped due to shared library event\n" Stopped due to shared library event 19*stopped,thread-id="1" (gdb) 20 info sharedlibrary &"info sharedlibrary\n" ~"From To Syms Read Shared Object Library\n" ~"0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0\n" ~"0x40011cc0 0x4001820c Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibpthread.so.0\n" ~"0x40029ca0 0x40030ec4 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibgcc_s.so.1\n" ~"0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0\n" 20^done (gdb) 21-exec-continue 21^running (gdb) ~"Stopped due to shared library event\n" Stopped due to shared library event 21*stopped,thread-id="1" (gdb) 22 info sharedlibrary &"info sharedlibrary\n" ~"From To Syms Read Shared Object Library\n" ~"0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0\n" ~"0x40011cc0 0x4001820c Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibpthread.so.0\n" ~"0x40029ca0 0x40030ec4 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibgcc_s.so.1\n" ~"0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0\n" 22^done (gdb) 23-exec-continue 23^running (gdb) 23*stopped,thread-id="1",frame={addr="0x00008784",func="main",args=[],fi le="sources/main.c",fullname="/buildhome/DU7PE/software/threading/source s/main.c",line="46"} (gdb) 24 info threads &"info threads\n" &"During symbol reading, incomplete CFI data; unspecified registers (e.g., r0) at 0x8780.\n" ~"* 1 Thread 912 main () at sources/main.c:46\n" 24^done (gdb) 25-stack-info-depth 25^done,depth="1" (gdb) 26-stack-list-frames 0 1 26^done,stack=[frame={level="0",addr="0x00008784",func="main",file="sour ces/main.c",fullname="/buildhome/DU7PE/software/threading/sources/main.c ",line="46"}] (gdb) 27-data-list-changed-registers 27^done,changed-registers=["0","1","2","3","4","5","6","7","8","9","10", "11","12","13","14","15","16","17","18","19","20","21","22","23","24","2 5"] (gdb) 28 info sharedlibrary &"info sharedlibrary\n" ~"From To Syms Read Shared Object Library\n" ~"0x40000930 0x40003eb0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l d-uClibc.so.0\n" ~"0x40011cc0 0x4001820c Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibpthread.so.0\n" ~"0x40029ca0 0x40030ec4 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibgcc_s.so.1\n" ~"0x40044c90 0x400855b0 Yes /buildhome/20090601/buildroot/project_build_arm/at91sam9g20ek/root/lib/l ibc.so.0\n" 28^done (gdb) 29-stack-list-arguments 0 0 0 29^done,stack-args=[frame={level="0",args=[]}] (gdb) 30-stack-list-locals 0 30^done,locals=[name="threads",name="rc",name="t"] (gdb) 31 whatis threads &"whatis threads\n" ~"type = pthread_t [5]\n" 31^done (gdb) 32 ptype pthread_t [5] &"ptype pthread_t [5]\n" ~"type = long unsigned int [5]\n" 32^done (gdb) 33 whatis rc &"whatis rc\n" ~"type = int\n" 33^done (gdb) 34 whatis t &"whatis t\n" ~"type = int\n" 34^done (gdb) 35-var-create - * threads 35^done,name="var1",numchild="5",value="[5]",type="pthread_t [5]" (gdb) 36-var-create - * &(threads) 36^done,name="var2",numchild="1",value="0xbec86d20",type="pthread_t (*)[5]" (gdb) 37-var-set-format var2 hexadecimal 37^done,format="hexadecimal",value="0xbec86d20" (gdb) 38 ptype pthread_t (*)[5] &"ptype pthread_t (*)[5]\n" ~"type = long unsigned int (*)[5]\n" 38^done (gdb) 39-var-evaluate-expression var2 39^done,value="0xbec86d20" (gdb) 40-var-create - * rc 40^done,name="var3",numchild="0",value="-1094160715",type="int" (gdb) 41-var-create - * t 41^done,name="var4",numchild="0",value="1074339480",type="int" (gdb) 42-var-evaluate-expression var3 42^done,value="-1094160715" (gdb) 43-var-evaluate-expression var4 43^done,value="1074339480" (gdb) 44-break-insert main.c:48 44^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr= "0x000087f8",func="main",file="sources/main.c",fullname="/buildhome/DU7P E/software/threading/sources/main.c",line="48",times="0"} (gdb) ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-06-03 15:21 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-05-26 16:02 Q: GDB - Threads Vellemans, Noel 2009-05-26 22:08 ` Hui Zhu 2009-06-02 15:27 ` Vellemans, Noel 2009-06-02 16:41 ` Paul Pluzhnikov 2009-06-02 18:17 ` Daniel Jacobowitz 2009-06-02 18:34 ` Paul Pluzhnikov 2009-06-02 19:34 ` Daniel Jacobowitz 2009-06-03 15:21 ` Vellemans, Noel 2009-06-02 19:42 ` Paul Pluzhnikov 2009-06-03 3:17 ` Hui Zhu 2009-06-03 9:26 ` Vellemans, Noel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox