Re: mips-linux-uclibc-gdb can't backtrace with core dump file.

["杜展" <zdu dot shanghai at gmail dot com>]

I'm awared that ld-uClibc.so was stripped of symbols. I rebuilt uClibc
and remain the debug info. Now backtrace can work. But can anyone
explain how dynamic linker works for gdb? Is there any docs? thanks.

2008/8/29, 杜展 <zdu.shanghai@gmail.com>:
> Hi,
>  I'm trying to use gdb on a mips board. I want to use gdb to analyze core file.
>  I download gdb V6.8, build with ./configure --host=mips-linux-uclibc
> --target=mips-linux-uclibc, I also
>  built libncurses which is missing with the same configure settings.
>  gdb can work on my board.
>  Then I build a simple program, test5.c
>
>  #include "common_header.h" //common_header.h is just
> everything-in-one header file collector
>  int main()
>  {
>        int i= 1;
>        printf("%s\n", i);
>  }
>
>  of course test5 will crash.
>
>  I copy test5 to board, run it, it crashed, core dumped.
>  Now I use gdb with : ./gdb test5 test5.core
>  Following are logs:
>  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 "mips-linux-uclibc"...
> Reading symbols from /lib/libc.so.0...
> warning: no loadable sections found in added symbol-file /lib/libc.so.0
> done.
> Loaded symbols for /lib/libc.so.0
> Reading symbols from /lib/ld-uClibc.so.0...
> warning: no loadable sections found in added symbol-file /lib/ld-uClibc.so.0
> done.
> Loaded symbols 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 `./test5'.
> Program terminated with signal 11, Segmentation fault.
> [New process 2002]
> #0  0x00000098 in ?? ()
> (gdb) bt
> #0  0x00000098 in ?? ()
> #1  0x2ab31944 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
>
>
> I don't have debug info in shared libs. But I think the backtrace can show the
> function names ,right?
>
> I searched some mails before regarding "Backtrace stopped: previous
> frame identical to this frame (corrupt stack?)",
> does it indicate the core dump file is bad?
>
> Then I built test5.c with "-g",
> use :./gdb test5
> r
> ...
> test5 crashed
> ...
> "bt"
> #0  0x2ab3d058 in ?? ()
> warning: GDB can't find the start of the function at 0x2ab3d058.
>
>    GDB is unable to find the start of the function at 0x2ab3d058
> and thus can't determine the size of that function's 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 0x2ab3d058 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.
> #1  0x2ab3d058 in ?? ()
> warning: GDB can't find the start of the function at 0x2ab3d057.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> then I'm completely confused...
>
> Can anyone help? Or you need more info, I'll be glad to provide. Thanks!
>