I’m having trouble with gdb when using a stripped executable and a separate debug symbols file. I’m trying to analyze a core dump from a stripped executable.
Here’s what I did:
Compiled a simple C program with debug info
Created a stripped executable and a separate debug file
Ran the stripped executable to generate a core dump
Tried to analyze the core dump with gdb
When I use the separate debug file, gdb can’t show info on local variables. It gives a ‘can’t compute CFA for this frame’ error.
I’ve tried:
Using just the stripped executable (no debug info)
Using the original unstripped executable (works, but with a warning)
Using the stripped executable with the separate debug file (gives the CFA error)
Questions:
Why does gdb warn about core file mismatch?
What’s causing the CFA error with separate debug files?
What’s a CFA anyway?
Am I creating or using the debug files wrong?
I want to use stripped executables in production and analyze core dumps with debug info on a dev system. How can I fix this issue?
I’ve encountered similar issues when working with stripped executables and separate debug files. The CFA (Canonical Frame Address) error often occurs when gdb can’t properly reconstruct the stack frame, which is crucial for accessing local variables.
A few things to check:
Ensure your debug symbols file matches exactly with the stripped executable. Even slight mismatches can cause issues.
Try using the add-symbol-file command in gdb to manually load the debug symbols, specifying the correct offsets.
Verify that your debug symbols weren’t accidentally stripped or corrupted during the separation process.
Check if your compiler and gdb versions are compatible. Sometimes, newer compiler optimizations can confuse older gdb versions.
As for the core file mismatch warning, it’s usually harmless but indicates that the core dump might have been generated from a slightly different version of the executable. This can happen due to minor updates or recompilations.
If these don’t help, you might need to adjust your build process or consider using a tool like eu-unstrip from elfutils to merge the debug info back into the core dump for analysis.
I’m really intrigued by your debugging adventure. Gdb can be such a tricky beast sometimes, right?
Have you considered using the objcopy command to add debug link information to your stripped executable? It might help gdb locate the separate debug file more reliably. Something like:
Also, I’m curious - what compiler flags are you using? Sometimes overly aggressive optimizations can make debugging a real headache. Maybe try compiling with -O0 just to rule that out?
Oh, and about that CFA (Canonical Frame Address) - it’s basically a way for debuggers to figure out where each stack frame starts. When gdb can’t compute it, it gets lost trying to unwind the stack.
Have you tried using info sharedlibrary in gdb to make sure all the libraries are loading correctly? Sometimes library mismatches can cause weird issues like this.
Let us know how it goes! Debugging can be frustrating, but it’s also kind of like solving a puzzle, isn’t it?
hey luke, had similar probs before. make sure ur debug file n stripped exe match exactly. tried eu-unstrip from elfutils? it can merge debug info back into core dump. might solve ur headache. also, check if compiler n gdb versions play nice together. sometimes newer compilers confuse older gdbs. good luck!
