Mark Baker wrote:
> As I understand it, debian distributing stripped binaries that originally
> had symbols in (rather than not putting them in in the first place) means
> that if I get a non-stripped binary it should have everything at the same
> addresses as the distributed one so should let me debug your core dump.
Wow, really? If so, that's a very good rationalle for requiring packages
be built with -g, even if DEB_BUILD_OPTIONS does not contain "debug".
However...
[EMAIL PROTECTED]:~>cat bad.c
main () {
static char *p;
int x;
for (x=0; x < 100000; x++)
p[x]=x;
}
[EMAIL PROTECTED]:~>gcc bad.c -o bad
[EMAIL PROTECTED]:~>./bad
zsh: segmentation fault (core dumped) ./bad
+ exit 139
[EMAIL PROTECTED]:~>gdb bad core
...
Core was generated by `./bad'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x80483ed in main ()
(gdb) bt
#0 0x80483ed in main ()
#1 0x4003df3c in __libc_start_main () from /lib/libc.so.6
(gdb) exit
[EMAIL PROTECTED]:~>gcc -g bad.c -o bad
[EMAIL PROTECTED]:~>gdb bad core
...
warning: exec file is newer than core file.
Core was generated by `./bad'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x80483ed in main () at bad.c:5
5 p[x]=x;
(gdb) bt
#0 0x80483ed in main () at bad.c:5
#1 0x4003df3c in __libc_start_main () from /lib/libc.so.6
(gdb) [EMAIL PROTECTED]:~>
So either I got lucky, or gdb can use the -g - built binary even with a core
file from a version that was not built with -g, and get proper stack tracing
and so on. Hmmm.
--
see shy jo
