This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Cross-platform, multithreaded debugging (x86 to ARM) with gdb and gdbserver not recognizing threads


> You want to copy /lib/libpthread.so.0 (which should be a symlink to
> /lib/libpthread-2.3.2.so) from target to host, and then:
>
>   arm-linux-nm libpthread.so.0 | egrep 'version|threads_events'
>
> You should see one of: nptl_version, __linuxthreads_version or
> __pthread_threads_events.

Sorry about that, I misread your last message.  libpthread.so isn't
stripped:

$ /opt/crosstool/gcc-3.4.4-glibc-2.3.2/arm-linux/bin/arm-linux-nm
libpthread-0.10.so | egrep 'version|threads_events'
0000de40 r __linuxthreads_version
00018e68 b __pthread_threads_events


> It is impossible to statically link libc.so.6 into an application.
Perhaps
> you mean that your app is linked with libc.a ?
>
> In general GDB may have harder time debugging statically-linked
threaded
> executables, and you should always prefer to link against system
libraries
> dynamically.

Yes, I did mean that I statically linked my application with libc.a.
Perhaps I'll reexamine my build environment as this may be the root of
my problems with GDB.  When running GDB natively on my target, I had no
problems debugging my application despite it being statically linked.
I'll do some tests to check whether addressing this allows gdb to
recognize threads in my remote application.

Thanks again,
Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]