3 ms·
C/C++ programs will normally have function names in backtraces, just not line numbers. $ cat test.c int g() { int *p = 0; *p = 5; } int f
by umanwizard 7y ago
C/C++ programs will normally have function names in backtraces, just not line numbers.
$ cat test.c
int g() {
int *p = 0;
*p = 5;
}
int f() {
g();
}
int main() {
f();
}
$ cc test.c
$ ./a.out
[1] 3377 segmentation fault (core dumped) ./a.out
$ gdb -q a.out core
Reading symbols from a.out...
(No debugging symbols found in a.out)
[New LWP 3377]
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000557379b7613d in g ()
(gdb) bt
#0 0x0000557379b7613d in g ()
#1 0x0000557379b76158 in f ()
#2 0x0000557379b7616d in main ()
- wahern 7y agoTry with -O3. Another wrinkle is that the symbol names of extern functions need to be in the binary regardless of debug level, though the main binary is a special case, unlike shared libraries. So you'll get different results again if you add -fPIC -rdynamic (or possibly just -fPIC) to -O3, similar results as-if you compiled a library with -O3 -fPIC -shared. But then if you define f and g as statically scoped -fPIC -rdynamic won't change the behavior. It follows that there's a potential conflict between code optimization and the ability to determine function names and line numbers for a trace. To preserve the ability to associate the programer counter (PC) to distinct function names and line numbers a compiler might need to abstain from completely inlining, merging, eliding, or otherwise optimizing some functions and code blocks (though that doesn't mean it needs to preserve actual function call behavior). People will endlessly debate the cost+benefit, but it's something to keep in mind for performance critical code blocks.