Proposed F18 feature: MiniDebugInfo
alexl at redhat.com
Tue May 8 06:34:57 UTC 2012
On Tue, 2012-05-08 at 08:30 +0200, Jakub Jelinek wrote:
> On Tue, May 08, 2012 at 08:09:04AM +0200, Alexander Larsson wrote:
> > This is your opinion. I rarely need the full backtrace in a bug report,
> > because it you can get one its generally something thats easily
> > reproduced and I can just run it in gdb myself. When you need it is when
> > something weird is happening and you have to rely on the bugreport only.
> > This is sometimes doable even without debug info, I even wrote a blog
> > post about this:
> > http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/
> > But, having the full symbol names for all libraries and apps in all
> > backtraces I'll ever see in the future would help me immensely. Even if
> > its "just an unwinder".
> But for that you really don't need the symtabs stored in the binaries/shared
> libraries, you can just have the backtrace without symbols printed + print
> relevant build-ids at the beginning, a script at any time can reconstruct
> that into not just the symbol names, but also lineinfo. And the build-ids
> will help even if you want to look at further details (.debug_info, source
Its true that that is all the information you need from the
process/core. But you need to have the rest of the information availible
*somewhere*, such as on a global retrace server or just having it
locally in the minidebuginfo. The later is far more robust and simple.
It lets you directly get a reasonable backtrace given *only* the actual
binaries in the running process.
More information about the devel