Fail to analyze core dump with GDB when main.elf is dynamically linked (uses shared libs)

Question

Hi all. I'm trying to analyze core dump, but i get following result.

If i make main.elf statically linked everything is OK and i can see bt of all threads. Any ideas?

GNU gdb 6.6.0.20070423-cvs
Copyright (C) 2006 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=mipsel-linux --target=mipsel-linux-uclibc".
(gdb) file main.elf 
Reading symbols from /home/tobi/main.elf...Reading symbols from /home/tobi/main.dbg...done.
done.
(gdb) core-file /srv/tobi/core
warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?)
Error while mapping shared library sections:
/lib/libdl.so.0: No such file or directory.
Error while mapping shared library sections:
/lib/librt.so.0: No such file or directory.
Error while mapping shared library sections:
/lib/libm.so.0: No such file or directory.
Error while mapping shared library sections:
/lib/libstdc++.so.6: No such file or directory.
Error while mapping shared library sections:
/lib/libc.so.0: No such file or directory.
warning: .dynamic section for "/lib/libgcc_s.so.1" is not at the expected address (wrong library or version mismatch?)
Error while mapping shared library sections:
/lib/ld-uClibc.so.0: No such file or directory.
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Symbol file not found for /lib/libdl.so.0
Symbol file not found for /lib/librt.so.0
Symbol file not found for /lib/libm.so.0
Symbol file not found for /lib/libstdc++.so.6
Symbol file not found for /lib/libc.so.0
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Symbol file not found for /lib/ld-uClibc.so.0
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Core was generated by 'root/main.elf'.
Program terminated with signal 11, Segmentation fault.
#0  0x0046006c in NullPtr (parse_p=0x2ac9dc80, result_sym_p=0x13e3d6c "") at folder/my1.c:1624
1624      *ptr += 13;
(gdb) bt
#0  0x0046006c in NullPtr (parse_p=0x2ac9dc80, result_sym_p=0x13e3d6c "") at folder/my1.c:1624
#1  0x0047a31c in fn1 (line_ptr=0x2ac9dd18 "ccore_null_pointer", target_ptr=0x13e3d6c "", result_ptr=0x2ac9dd14) at folder/my2.c:980
#2  0x0047b9d0 in fn2 (macro_ptr=0x0, rtn_exp_ptr=0x0) at folder/my3.c:1483
/... some functions .../
#8  0x2aab7f9c in __nptl_setxid () from /lib/libpthread.so.0
Backtrace stopped: frame did not save the PC
(gdb) thread apply all bt

Thread 159 (process 1093):
#0  0x2aac15dc in _Unwind_GetCFA () from /lib/libpthread.so.0
#1  0x2afdfde8 in ?? ()
warning: GDB cant find the start of the function at 0x2afdfde8.

    GDB is unable to find the start of the function at 0x2afdfde8
and thus cant determine the size of that functions stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2afdfde8 for code which looks like the beginning of a
function, you can increase the range of the search using the set
heuristic-fence-post command.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 158 (process 1051):
#0  0x2aac17bc in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
#1  0x2aac17a0 in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 157 (process 1057):
#0  0x2aabf908 in ?? () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Thread 156 (process 1090):
#0  0x2aac17bc in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
#1  0x2aac17a0 in pthread_mutexattr_getprioceiling () from /lib/libpthread.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 155 (process 1219):
#0  0x2aabf908 in ?? () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Thread 154 (process 1218):
#0  0x2aabfb44 in connect () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Thread 153 (process 1096):
#0  0x2abc92b4 in ?? ()
warning: GDB cant find the start of the function at 0x2abc92b4.
#1  0x2abc92b4 in ?? ()
warning: GDB cant find the start of the function at 0x2abc92b4.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 152 (process 1170):
#0  0x2aabfb44 in connect () from /lib/libpthread.so.0
#1  0x00000000 in ?? ()

Answer 1

You need tell the gdb where it can find its shared-libraries. I suppose you are cross-debugging a core that was generated on another system?

Google for "set solib-absolute-prefix".

Answer 2

Guys, thanks you all a lot!

All i needed to do is

set solib-absolute-prefix [path-to-libs]

BEFORE loading an executable and core files :DDDD