From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15941 invoked by alias); 30 Jun 2008 20:25:23 -0000 Received: (qmail 15933 invoked by uid 22791); 30 Jun 2008 20:25:22 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from accolon.hansenpartnership.com (HELO accolon.hansenpartnership.com) (76.243.235.52) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jun 2008 20:24:54 +0000 Received: from localhost (localhost [127.0.0.1]) by accolon.hansenpartnership.com (Postfix) with ESMTP id E0B0D83F8; Mon, 30 Jun 2008 15:24:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1214857492; bh=VytVbL9M0CVBAobW+h/L/K3aCjL67kfwQUqUtlqn+h Q=; l=2192; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=DbhVOFqvoI+Ad0vGwY+9rJ6VhbY7k7P6zTl+C 9IMBHumeoDfdr1a6G3BF8ZhqNE81EnplFEhqFyMeiCcMWkecFozNgcmo94OrFehMVNy 2TMJpNy8Hm6NsWT0d4XvrljCaT9Eq5+T+Zf9RO/QQL/ZVopHr/qUMuw/Y6yBJfvcJyM = Received: from accolon.hansenpartnership.com ([127.0.0.1]) by localhost (redscar.int.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khVs1r0GaZtG; Mon, 30 Jun 2008 15:24:50 -0500 (CDT) Received: from [153.66.150.222] (mulgrave-w.int.hansenpartnership.com [153.66.150.222]) by accolon.hansenpartnership.com (Postfix) with ESMTP id 2AFB0828D; Mon, 30 Jun 2008 15:24:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1214857490; bh=VytVbL9M0CVBAobW+h/L/K3aCjL67kfwQUqUtlqn+h Q=; l=2192; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=MNUWuOQ7fbmo3yU7CVfg4PDP8952wrsaV10w8 BG8nqMBpjK+mo/pfAGzzgChmlQ2hwLA+xHb9FoTGylAqCiso9FPeP+4Vkdy5hgoBnto yjjM2nyJc0VjhJW+rqJSkXToq6DL7ail2mDIYvMTzWgNeWk+h3QqsWGcVsL859IYjEo = Subject: Re: [Ksummit-2008-discuss] DTrace From: James Bottomley To: Theodore Tso Cc: "Frank Ch. Eigler" , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com In-Reply-To: <20080630201031.GF7988@mit.edu> References: <20080630010423.GA7068@redhat.com> <20080630181959.GA7988@mit.edu> <20080630192533.GE21660@redhat.com> <20080630201031.GF7988@mit.edu> Content-Type: text/plain Date: Mon, 30 Jun 2008 21:13:00 -0000 Message-Id: <1214857489.3381.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00817.txt.bz2 On Mon, 2008-06-30 at 16:10 -0400, Theodore Tso wrote: > Stupid question --- has anyone thought about writing tools to strip > out specific debug information not needed by Systemtap? For example, > I assume systemtap doesn't need the line number information, since you > can't set probes on arbitrary line numbers (and even if you could, > such tapsets would be so brittle that it wouldn't be funny); so would > the debuginfo files be smaller if that information were stripped out? > I understand that this would make the files less useful for > kdump/crash, but for systemtap only users, it might be quite useful. > What about stripping out the text segment of the object files, so you > aren't storing the information twice on disk, or compressing the > debuginfo files so they take up less room on disk? Actually, you can ... and I know it's brittle, but I do use this feature a lot (there's no other way to get at local variables currently than by specifying a line number through the statement interface). I believe the point of the markers project is to add pieces to the kernel that identify useful (and invariant) internal points in the routines where you can get at the local variables without having to specify line numbers. The debug information is bulky because dwarf is so damn wasteful. Practically every kernel module will contain the dwarf definition of certain central structures. When a debugger works on an executable, it first of all builds up and in house view of all the dwarf statements, combining all of the duplicate symbols. If we could find a way of doing that for the kernel and then spitting it out as a single file, it would be far smaller than the debuginfo. Assuming we don't want a monolith, but actual reduced files (so that modules can be added) we immediately run across the other annoying thing with dwarf: it has a mechanism to stub out definitions (DW_AT_declaration) but no way of providing input about where the real definition is (you now have to search the entire tree to find it). Unfortunately, you really have to do these type of reduction tricks, and strip really just won't do them usefully. James