From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25752 invoked by alias); 1 Jul 2008 20:06:58 -0000 Received: (qmail 25742 invoked by uid 22791); 1 Jul 2008 20:06:56 -0000 X-Spam-Status: No, hits=-1.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; Tue, 01 Jul 2008 20:06:37 +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 m61K6Zcv031301 for ; Tue, 1 Jul 2008 16:06:35 -0400 Received: from gateway.sf.frob.com (vpn-13-4.rdu.redhat.com [10.11.13.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m61K6XTU002229; Tue, 1 Jul 2008 16:06:33 -0400 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 9DFE9357B; Tue, 1 Jul 2008 13:06:32 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 6790A1541F5; Tue, 1 Jul 2008 13:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Theodore Tso X-Fcc: ~/Mail/linus Cc: "Frank Ch. Eigler" , ksummit-2008-discuss@lists.linux-foundation.org, systemtap@sources.redhat.com Subject: Re: [Ksummit-2008-discuss] DTrace In-Reply-To: Theodore Tso's message of Tuesday, 1 July 2008 06:15:07 -0400 <20080701101507.GB22717@mit.edu> References: <20080630010423.GA7068@redhat.com> <20080630181959.GA7988@mit.edu> <20080630192533.GE21660@redhat.com> <20080630201031.GF7988@mit.edu> <20080630204219.GA6631@redhat.com> <20080701024140.GB28143@mit.edu> <20080701070746.C6DAD15420E@magilla.localdomain> <20080701101507.GB22717@mit.edu> X-Shopping-List: (1) Athletic removers (2) Resentful fission persuaders (3) Galactic pajamas Message-Id: <20080701200632.6790A1541F5@magilla.localdomain> Date: Tue, 01 Jul 2008 20:06:00 -0000 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-q3/txt/msg00012.txt.bz2 Like I said, the essential command is eu-strip -f. It is simple to use. For one's own local hacking purposes, there is no real reason to bother with strip-to-file complexities. You can just copy the unstripped files before stripping them. The effect is the same (or easier for you, with most of the tools), and the extra 6M (stripped) where you have disk space for the 60M (debuginfo) is never an issue (i.e. if it's 66M unstripped). In the Fedora packaging, an ELF vmlinux file in /boot is treated the same as the .ko files (and all installed binaries for any package) and gets the strip-to-file treatment. It works the same on ELF executables (be they kernels or otherwise), DSOs, and .ko's. There is a special case in the kernel packaging when what's in /boot is not in ELF format (i.e. bzImage format and such)--the strip-to-file convention requires having the stripped ELF file intact and on hand too. When there won't be any plain ELF vmlinux in /boot, we just copy the unstripped vmlinux into /usr/src/debug. I honestly don't think it's ever going to be useful to any distro build to have kernel makefiles do .debug file splitting. For purposes of separate debuginfo, the kernel really isn't a very special package. The distro packaging magic needs to do its debuginfo diddling, strip-to-file, and related cataloguing magic for all packages anyway. All the packagers have to do for each individual package is get it to compile with -g and not strip the binaries it installs. The packaging hooey takes care of the rest, and having a package's "make install" try to "do it for you" would just break everything. Future distro magic will evolve with newer tools to pack the .debug file data in different, better ways, etc. It just is not going to help packagers to have any version of such logic built into the kernel build process. That said, knock yourself out. I'm glad to answer questions about the tools. But we have gone pretty darn far afield from this thread's topic now. This does not seem like the logical place to pursue those technical details of the toolchain. Thanks, Roland