3

Just being curious: When I load a core file in gdb, the backtraces look like this:

...

Thread 2 (Thread 1109):
#0  0x2b03d968 in ?? ()

Thread 1 (Thread 23490):
#0  0x2b0c3624 in ?? ()
(gdb)

But after I load the binary using 'file', I get this:

...

#0  __pthread_cond_wait (cond=0x46b810, mutex=0x46b7f0) at pthread_cond_wait.c:156
#1  0x004076a8 in main (argc=1, argv=0x7fa66784) at idpoint.c:258
...

#0  0x2b0c3624 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x2b0c8464 in *__GI_abort () at abort.c:88
#2  0x2b0faeec in __libc_message (do_abort=2, fmt=0x2b1d0840 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:173
#3  0x2b107e3c in malloc_printerr (action=3, str=0x2b1d0930 "free(): invalid next size (fast)", ptr=<value optimized out>) at malloc.c:5994
...

Question: Why doesn't gdb even make an attempt to display a call stack before symbols are loaded? My guess is that it has no idea of where segments are placed in memory and can't know which stack data to interpret as data vs. addresses? Is this correct?

It would be nice if it was possible to get gdb:s best attempt at displaying a call stack without symbols, to get an idea of stack depths, or for later interpretation...

Rumpsteak
  • 95
  • 1
  • 11
  • 1
    What do you mean when you say "unwinding"? http://stackoverflow.com/questions/2331316/what-is-stack-unwinding You want GDB to tell you the call stack? – Kijewski Feb 14 '13 at 10:23

1 Answers1

3

Because the binary file contains symbolic information (debug symbols) that allow the debugger to understand, for example, how big the stackframe is for each function [at any given time in the function as well!]. This information is not loaded into memory when the code is started, so there is no way for it to be in the core file.

You can of course use x/200 $esp (or whatever the stack pointer is called - I'm guessing x86 - if it's ARM, then it's called $R15 from memory). Unfortunately, without having access to the symbols, gdb won't really know what is what on the stack, and would only be able to just provide a raw dump of the stack - which would in most cases be even less helpful than not showing anything, as showing a load of random data (and most of the stack will be - especially if frame pointers are turned off - with frame pointers you have some chance of un-nesting the stack) is pretty useless most of the time.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Alright, I was thinking that maybe gdb could make qualified guesses as to which pieces of the "random data" would be return addresses, but perhaps that is too much to ask... – Rumpsteak Feb 14 '13 at 12:47