I'm having a hard time generating breakpad symbols on Linux from stripped binaries.
I compile with:
gcc-4.4 -c -I../include -D_LINUX -m64 -fPIC -D__LP64__ -D_GNU_SOURCE -Wno-switch -Wno-missing-braces -fno-strict-aliasing -Wreturn-type -Wall -Wno-unknown-pragmas -Wno-parentheses -pipe -fmessage-length=0 -g -DRELEASE -O3 -o lin/voxl.o voxl.c -fvisibility=hidden
There are also some C++ files.
I then link with:
g++-4.4 -o ../liblin/foo.so -shared <objects> <libs> -z origin -Wl,-R,\$ORIGIN -Wl,-rpath,../liblin
And finally strip debug information into .debug files with:
objcopy --only-keep-debug ../liblin/foo.so ../liblin/foo.so.debug
objcopy --strip-debug ../liblin/foo.so
objcopy --add-gnu-debuglink=../liblin/foo.so.debug ../liblin/foo.so
The resulting binary can be debugged with GDB with full symbol information. It contains a .gnu_debuglink section which refers to foo.so.debug (no dir path), which is correct.
However, dump_syms doesn't seem to be following the link, even though the code being edited in this patch strongly suggests that it should. I get this output in stderr:
liblin/foo.so, section '.eh_frame': the call frame entry at offset 0x18 uses a DWARF expression to describe how to recover register '.cfa', but this translator cannot yet translate DWARF expressions to Breakpad postfix expressions
liblin/foo.so: file contains no debugging information (no ".stab" or ".debug_info" sections)
The resulting symbol file is 2MB, whether or not the .gnu_debuglink section is present in the ELF. When using this 2MB symbol file with minidump_stackwalk, the wrong functions appear on stack frames. When I run dump_syms on a binary with embedded symbols the output file is 9MB and stack frames are correct.
What am I doing wrong?
This turned out to be two things:
dump_syms, even if the symbols are in the same folder as the binaries. e.g. dump_syms foo.so .