From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17581 invoked by alias); 19 Dec 2008 23:51:50 -0000 Received: (qmail 17574 invoked by uid 22791); 19 Dec 2008 23:51:50 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate4.uk.ibm.com (HELO mtagate4.uk.ibm.com) (195.212.29.137) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Dec 2008 23:51:06 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id mBJNp4VJ086688 for ; Fri, 19 Dec 2008 23:51:04 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBJNp3Hl3113072 for ; Fri, 19 Dec 2008 23:51:03 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mBJNp3Z2026149 for ; Fri, 19 Dec 2008 23:51:03 GMT Received: from d06ml065.portsmouth.uk.ibm.com (d06ml065.portsmouth.uk.ibm.com [9.149.38.138]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mBJNp3Gq026144; Fri, 19 Dec 2008 23:51:03 GMT In-Reply-To: <494BFBBF.3090804@redhat.com> References: <494A053D.4030808@hitachi.com> <20081219085519.041D.KOSAKI.MOTOHIRO@jp.fujitsu.com> <20081219004423.GB24081@redhat.com> <494BFBBF.3090804@redhat.com> Subject: Re: Discussion at Linux Foundation Japan Symposium X-KeepSent: FD2BE987:11C7BFF2-80257524:00816D95; type=4; name=$KeepSent To: William Cohen Cc: "Frank Ch. Eigler" , hisashi.hashimoto.wh@hitachi.com, KOSAKI Motohiro , mhiramat@redhat.com, Satoshi OSHIMA , systemtap@sourceware.org, Yumiko SUGITA X-Mailer: Lotus Notes Release 8.0.2 August 07, 2008 Message-ID: From: Richard J Moore Date: Sat, 20 Dec 2008 01:51:00 -0000 X-MIMETrack: Serialize by Router on D06ML065/06/M/IBM(Release 8.0.1|February 07, 2008) at 19/12/2008 23:51:02 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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-q4/txt/msg00619.txt.bz2 systemtap-owner@sourceware.org wrote on 19/12/2008 19:53:35: > [image removed] > > Re: Discussion at Linux Foundation Japan Symposium > > William Cohen > > to: > > Frank Ch. Eigler > > 19/12/2008 19:54 > > Sent by: > > systemtap-owner@sourceware.org > > Cc: > > KOSAKI Motohiro, Satoshi OSHIMA, systemtap, mhiramat, > hisashi.hashimoto.wh, Yumiko SUGITA > > Frank Ch. Eigler wrote: > > Hi - > > > > On Fri, Dec 19, 2008 at 08:58:58AM +0900, KOSAKI Motohiro wrote: > >>>> Systemtap always requires kernel debuginfo to use. Unfortunately, > >>>> it is hard for users of some distributions to have debuginfo. > >>> Those distributions ought to be lobbied to improve this situation, > >>> since there are many non-systemtap uses of debugging data - such as > >>> debuggers, kernel- and user-space crash dump analysis tools. > >> [...] > >> In enterprise usage, crash dump analysis is provided by vendor. > >> but tapset run on customer. [...] > > > > That is just one scenario. Another compelling use for debuginfo is a > > tool like oprofile. > > > > - FChE > > For the case where oprofile data is being mapped back to lines in the source > code debuginfo is needed. However, for the case just want to know which > functions the code is spending time in oprofile doesn't use debugging > information produced by -g; it just looks for the function locations in the > code. Unfortunately, the strip operations used for binaries in distribution > strip out all information from the binary leaving just the minimal executable > bits, making the debuginfo the only place to get that information. > > It would be nice if there was something between the extremes of a > huge amount of > information in the debuginfo or nothing at all. > > > -Will I attempted to reply to this earlier but it never made the mailing list, apologies for repeating myself to those who did read my earlier response.: My suggestion and hope is that we can weakening the dependency between SystemTap and debuginfo. On taking a look back to the antecedents to kprobes i.e dprobes and before that dtrace for OS/2 we didn't rely explicitly on debuginfo. Both dprobes and dtrace would use the debuginfo if available but would also work with public symbols in the module header and with expressions based on these symbols. Is this useable? Yes it is: for one-off debugging scenarios I often used a crashdump to begin the anbalysis and would follow up with a probe based on what I say in the dump. It's relatively easy, when dealing with the binary data to develop probe expressions based on offsets to public symbols. This would be useful but would require System Tap to change. For performance investigation and regular tracing, the probes can generally be developed in advance of their need. What we did with OS/2 was to build probe binaries based on debuginfo as part of the module build. Once the binary was build there was no need for debuginfo to be present to execute the probe. So we stripped the debuginfo from the module and shipped the stripped module along with its probe binary. We could do something similar with SystemTap especially for the pre-built probe libraries. Debug info is only really needed when developing probes without access to a dump. I think a lot of mileage could be gained from System Tap by having pre-built probe modules that matched a given distro service pack or kernel build. We wouldn't need to change System Tap to support this. We could then concentrate on providing a host of useful pre-built probe modules. Richard M.