This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stabs vs dwarf (was: Re: Wrong address for static function in linux module )


> Date: Wed, 12 Apr 2006 20:24:56 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: drow@false.org, jr.peulve@wanadoo.fr, gdb@sources.redhat.com
> 
> > Date: Wed, 12 Apr 2006 11:38:09 -0400
> > From: David Taylor <dtaylor@emc.com>
> > 
> > A full build tree (build products only, no sources) is 8.7 GB with
> > STABS, but 24.6 GB when built with -gdwarf-2 -feliminate-dwarf2-dups.
> 
> You know if you compiled without debug information, your build tree
> would be even smaller.  What matters is whether the debug info is
> actually usable.  For unoptimized C code, stabs is probably fine.  But
> for heavily optimized C++ code, it will be unusable.

On the other hand, if the ``usable'' debug info uses up space that is
comparable to what the sources use up, we might as well ditch the
debug info, and instead implement an option in GCC that would use it
as an agent for telling GDB what it needs to know, and _only_ what it
needs to know.  That is, GDB would invoke GCC and ask it to provide
the info about some variable or function, and GCC will glean that from
the sources.

This is only a half-serious suggestion, the point being that a debug
info that is not optimized for debugger's usability in terms of memory
footprint and on-demand loading, is not very ``usable'', IMHO.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]