From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27857 invoked by alias); 13 Apr 2006 08:10:08 -0000 Received: (qmail 27834 invoked by uid 22791); 13 Apr 2006 08:10:07 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 13 Apr 2006 08:10:04 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-205-75.inter.net.il [83.130.205.75]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DDC08581 (AUTH halo1); Thu, 13 Apr 2006 11:08:47 +0300 (IDT) Date: Thu, 13 Apr 2006 08:26:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: dtaylor@emc.com, jr.peulve@wanadoo.fr, gdb@sources.redhat.com In-reply-to: <200604121824.k3CIOuJm000173@elgar.sibelius.xs4all.nl> (message from Mark Kettenis on Wed, 12 Apr 2006 20:24:56 +0200 (CEST)) Subject: Re: stabs vs dwarf (was: Re: Wrong address for static function in linux module ) Reply-to: Eli Zaretskii References: <6.1.0.6.0.20060411102654.00ad0710@pop.wanadoo.fr> <20060411131142.GA21521@nevyn.them.org> <6.1.0.6.0.20060411152707.00acc440@pop.wanadoo.fr> <20060411133836.GA22167@nevyn.them.org> <6.1.0.6.0.20060411163043.00a957f0@pop.wanadoo.fr> <20060411144002.GA27443@nevyn.them.org> <200604121538.k3CFc9Mm005686@mailhub.lss.emc.com> <200604121824.k3CIOuJm000173@elgar.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00153.txt.bz2 > Date: Wed, 12 Apr 2006 20:24:56 +0200 (CEST) > From: Mark Kettenis > CC: drow@false.org, jr.peulve@wanadoo.fr, gdb@sources.redhat.com > > > Date: Wed, 12 Apr 2006 11:38:09 -0400 > > From: David Taylor > > > > 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.