From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13948 invoked by alias); 30 Jun 2008 20:23:26 -0000 Received: (qmail 13941 invoked by uid 22791); 30 Jun 2008 20:23:26 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jun 2008 20:22:39 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5UKMbo2019297 for ; Mon, 30 Jun 2008 16:22:37 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5UKMaH9016072; Mon, 30 Jun 2008 16:22:36 -0400 Received: from doppio.ghostprotocols.net (vpn-13-158.rdu.redhat.com [10.11.13.158]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5UKMZCT019734; Mon, 30 Jun 2008 16:22:35 -0400 Received: by doppio.ghostprotocols.net (Postfix, from userid 500) id 7F6092200E3; Mon, 30 Jun 2008 17:22:33 -0300 (BRT) Date: Mon, 30 Jun 2008 21:12:00 -0000 From: Arnaldo Carvalho de Melo To: Theodore Tso Cc: "Frank Ch. Eigler" , "David S. Miller" , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace Message-ID: <20080630202233.GC15832@ghostprotocols.net> References: <20080630010423.GA7068@redhat.com> <20080630181959.GA7988@mit.edu> <20080630192533.GE21660@redhat.com> <20080630201031.GF7988@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630201031.GF7988@mit.edu> X-Url: http://oops.ghostprotocols.net:81/blog User-Agent: Mutt/1.5.18 (2008-05-17) X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes 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/msg00816.txt.bz2 Em Mon, Jun 30, 2008 at 04:10:31PM -0400, Theodore Tso escreveu: > On Mon, Jun 30, 2008 at 03:25:33PM -0400, Frank Ch. Eigler wrote: > > > The problem is that kernel developers are often juggling multiple > > > kernels, so kernel developers need to learn how to package up this > > > bulky data as well. > > > > They shouldn't have to repackage it at all - just leave it in the > > build tree. > > The problem is that I am often juggling multiple kernel builds, and so > I don't want to keep the full build tree around. So I just want to > extract out the specific files needed by Systemtap, especially becuase > they are so bulky. So normally I actually do create specific packages > for the kernels I use (so I can give them to others or put them on my > server machines if they prove to be stable), and I want to be able to > package up the debuginfo files as well --- and only exactly the > debuginfo files which are needed to make systemtap work. > > 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? Yes, its called CTF, Compressed C Type Format, in DTrace land: http://opensolaris.org/os/project/ppc-dev/task_map/ctf/ DaveM wrote a CTF loader that I included in my dwarves package, so that we can pretty-print and use all the other features in pahole on files with CTF sections, such as the Open Solaris kernel and the userland binaries, that all ship with CTF embedded, dispensing the usage of -debuginfo packages, all AFAIK. In my TODO I have "encode CTF from DWARF and make it a part of the kernel building process" together with "publish results about the savings obtained", how much would be added to the kernel image so that we always ship the, by then compressed debugging information, to the kernel. I hope to get back to working on this RSN. - Arnaldo