I'm at a stage in a project where it would be really handy to have a debug version of a system package installed. On Ubuntu at least, adding the debug symbols to a library is a piece of cake. Practically every package has a -dbg
variant that provides all the symbols you'd need for a useful backtrace.
However, I'm currently on Arch linux, where the general concensus is to edit the user makepkg.conf
file, adding whatever debug flags to (C|CXX|CPP|LD)FLAGS
. Then re-build the package yourself, and replace the current, optimised version with the debug build. Well, I suppose that's fair enough with a "source-based distribution", but it gets tedious pretty quickly.
So, what is / are the best practices for attaching debug symbols to a system package? How do other packagers do it?
I think I've seen that strip
can extract debug symbols and save them in external files. Is it possible for gdb
to pick up those symbol files during backtraces, with system applications not even bothering to look for them? How does that work, from a packagers perspective?
It's just an idea, but is it a good idea to create a chroot
environment in which to develop? (I have a problem atm where a package has an ABI incompatibility between its debug and release builds, which is a bit of a pain. Everything linked to its shared lib also complains about missing symbols, so reverted to optimised build..)
OPTIONS+=(debug !strip)
adds this (from/etc/makepkg.conf
) to your build options:DEBUG_CFLAGS="-g -fvar-tracking-assignments"
. Neither of these disables any optimizations. You get an optimized build with debug symbols, not what many people mean when they talk about a "debug build". When you debug with gdb, oftenprint some_local
will give you(optimized out)
, because the debug format can't track variables that are live in registers. (As well as cases where a variable really was optimized out, and no register or memory holds a value matching the C source.)