Re: Restarting gdbserver

[Leon Pollak <leonp@plris.com>]

Jan, I start to understand...:-)

You say that the libpthread shared library does not have debug info in it. 

OK, to check myself and understand your explanation, I compiled the same 
application in the "normal" Fedora 12 - it does show the backtrace.

I ran 'i shared' command in both cases. 
Fedora case - exactly what I need:
From        To          Syms Read   Shared Object Library
0x0065a830  0x006720bf  Yes (*)     /lib/ld-linux.so.2
0x00114170  0x00122b28  Yes (*)     /lib/libnsl.so.1
0x009a3880  0x009a7678  Yes (*)     /lib/librt.so.1
0x00809a60  0x0080aa88  Yes (*)     /lib/libdl.so.2
0x008145e0  0x00820518  Yes (*)     /lib/libpthread.so.0
0x0016eeb0  0x001e1838  Yes (*)     /usr/lib/libstdc++.so.6
0x00830470  0x0084a968  Yes (*)     /lib/libm.so.6
0x00218fa0  0x002313c8  Yes (*)     /lib/libgcc_s.so.1
0x00692aa0  0x007b11f4  Yes (*)     /lib/libc.so.6
(*): Shared library is missing debugging information.
(gdb) bt
#0  0x00110430 in __kernel_vsyscall ()
#1  0x0081a22c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x08078757 in ucc::Conditional::wait() ()
#3  0x0807c15b in ucc::queue::fifo (this=0x80a07e0, timeout=4294967295) at 
/Projects/ucommon.3.0.5/common/thread.cpp:2115
#4  0x0806efd2 in cDispatcher::Processor (this=0x80a08a4) at 
/Projects/CSU/src/Dispatcher.cpp:94
#5  0x0806d323 in main () at /Projects/CSU/src/main.cpp:27
=============================

Cross-linux case:
(gdb) i shared
From        To          Syms Read   Shared Object Library
0x400007e0  0x40018ab4  Yes (*)     /opt/FS/lib/ld-linux.so.3
0x40029ce0  0x400383e8  Yes (*)     /opt/FS/lib/libpthread.so.0
0x4005d9f8  0x400a505c  Yes         /opt/FS/lib/libucommon.so.3
0x400f8664  0x4017358c  Yes (*)     /opt/FS/usr/lib/libstdc++.so.6
0x40199234  0x40201264  Yes (*)     /opt/FS/lib/libm.so.6
0x40243248  0x4024b2c8  Yes (*)     /opt/FS/lib/libgcc_s.so.1
0x40268990  0x4034e710  Yes (*)     /opt/FS/lib/libc.so.6
0x4037a640  0x4037dc6c  Yes (*)     /opt/FS/lib/librt.so.1
0x40388974  0x403896f0  Yes (*)     /opt/FS/lib/libdl.so.2
(*): Shared library is missing debugging information.
(gdb) bt
#0  0x400314bc in pthread_cond_wait@@GLIBC_2.4 () from 
/opt/FS/lib/libpthread.so.0
#1  0x00000000 in ?? ()
=======================================

In both cases gdb says "Shared library is missing debugging information"!
And I searched my Fedora installatoin - no *debug*.so at all.

So, how all this works?


Thank you very much for your lessons...:-)

On Sunday January 23 2011, Jan Kratochvil wrote:
> On Sun, 23 Jan 2011 17:43:44 +0100, Leon Pollak wrote:
> > Thank you, Jan.
> > 
> > I hope I understood and did what you said:
> > 
> > bash-4.1$ ./gdb -nx -ex file /opt/FS/common/csu -ex target
> > extended-remote 192.168.50.4:44000 -ex set sysroot /opt/FS -ex set
> > remote exec-file /common/csu -ex start
> > GNU gdb (GDB) 7.2
> > Copyright (C) 2010 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=x86_64-unknown-linux-gnu
> > --target=armv5tl- montavista-linux-gnueabi".
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>.
> > Reading symbols from /opt/FS/common/csu...done.
> > Remote debugging using 192.168.50.4:44000
> > Temporary breakpoint 1 at 0x20374: file /Projects/CSU/src/main.cpp, line
> > 16. Starting program: /opt/FS/common/csu
> > 
> > Temporary breakpoint 1, main () at /Projects/CSU/src/main.cpp:16
> > 16              MsgLog("OFP Version: %s dated %s", OFP_VERSION,
> > __TIMESTAMP__);
> > (gdb) c
> > Continuing.
> > ^C
> > Program received signal SIGINT, Interrupt.
> > 0x400314bc in pthread_cond_wait@@GLIBC_2.4 () from
> > /opt/FS/lib/libpthread.so.0 (gdb) bt
> > #0  0x400314bc in pthread_cond_wait@@GLIBC_2.4 () from
> > /opt/FS/lib/libpthread.so.0
> > #1  0x00000000 in ?? ()
> > (gdb)
> > -------------------------------------------------------------------------
> > --- God knows why it decided to stop at main...
> 
> This is done intentionally by the GDB command `start'.
> 
> > Is it what you meant?
> 
> So symbols from /opt/FS/common/csu work as can be seen in the main
> function.
> 
> Symbols from remote `/lib/libpthread.so.0' do not work. I guess it uses
> separate debug info.  You can try:
> readelf -wi /opt/FS/lib/libpthread.so.0
> readelf -wi /opt/FS/usr/lib/debug/opt/FS/lib/libpthread.so.0
> readelf -wi /opt/FS/usr/lib/debug/opt/FS/lib/libpthread.so.0.debug
> # There are just guesses, it depends on the montavista distro from which
> comes # /opt/FS/lib/libpthread.so.0 and I do not know montavista. readelf
> should # come from the montavista cross binutils package.
> 
> I guess you should really use also the part of the reproducer from me:
>   -ex 'set debug-file-directory /host1/usr/lib/debug
> that is in your case:
>   -ex 'set debug-file-directory /opt/FS/usr/lib/debug
> 
> And you should also verify the separate debug info files from montavista
> are installed under /opt/FS/usr/lib/debug (for example *-debuginfo.rpm
> packages in Fedora).
> 
> 
> Regards,
> Jan


--