From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25426 invoked by alias); 1 Nov 2006 19:07:32 -0000 Received: (qmail 25358 invoked by uid 22791); 1 Nov 2006 19:07:29 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Nov 2006 19:07:18 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kA1J7CuH015976 for ; Wed, 1 Nov 2006 14:07:12 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA1J6qZv324750 for ; Wed, 1 Nov 2006 12:06:55 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA1J6pmD003388 for ; Wed, 1 Nov 2006 12:06:52 -0700 Received: from [9.67.119.243] (wecm-9-67-119-243.wecm.ibm.com [9.67.119.243]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA1J6nM8003250; Wed, 1 Nov 2006 12:06:50 -0700 Message-ID: <4548F8BD.5050008@us.ibm.com> Date: Wed, 01 Nov 2006 19:09:00 -0000 From: David Wilder User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Smith CC: "Frank Ch. Eigler" , ken@odtv.com, "'Badari Pulavarty'" , systemtap@sources.redhat.com Subject: Re: Anyone tried SystemTap with the latest RHEL5 Beta refresh References: <20061101013734.GU4978@redhat.com> <017f01c6fd83$da5ed930$0301a8c0@wxp1mbl1> <4548DB65.5020202@us.ibm.com> <4548D711.2060904@redhat.com> <4548EA74.7000105@us.ibm.com> <4548EC3C.9080800@redhat.com> In-Reply-To: <4548EC3C.9080800@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00320.txt.bz2 David Smith wrote: > David Wilder wrote: > >> David Smith wrote: >> >>> David Wilder wrote: >>> >>>> Frank Ch. Eigler wrote: >>>> >>>>> "Ken Robson" writes: >>>>> >>>>> >>>>> >>>>>> [...] To me it is valid to install minus the debuginfo files on >>>>>> almost all Production hosts. I am experimenting with developing my >>>>>> scripts off box with my cache directory set to an exported read-only >>>>>> NFS share which is then mounted as the module cache directory on my >>>>>> Production boxes [...] >>>>>> >>>>> >>>>> >>>>> >>>>> More than that - on such production boxes, you will need to install >>>>> only the "staprun" (formerly "stapd") binary, now separated into a >>>>> systemtap-runtime RPM. For the moment though please be careful with >>>>> building probes for mismatching machines: the module address tables >>>>> are not yet fully adaptive. >>>>> >>>>> - FChE >>>>> >>>>> >>>> The cached debuginfo is a really cool concept. >>> >>> >>> >>> You got a bit confused here. The debuginfo isn't cached, the >>> systemtap compiled modules are cached. >> >> >> >> Thanks for the clarification. >> >>> >>>> But it wont solve the problem of simplifying the use of systemtap >>>> for the customers. From a support standpoint if a customer system >>>> is missing a debug tool (or some dependent component) the tool may >>>> as well not exist! If it comes down to fix the debug tool or find >>>> another approach to solve the customers problem the later will >>>> generally win. To make stap successful we need to get people using >>>> it and providing feedback, let's make it as easy as possible to >>>> use. All dependencies must be installed when selecting a product >>>> for install. >>> >>> >>> >>> In general, I certainly agree with you that all dependencies must be >>> installed. >>> >>> However, systemtap (and any other program that would like to use >>> debuginfo) is a special case. From my understanding, there is a >>> policy (perhaps unwritten) that no rpm can require a debuginfo rpm. >>> Plus, even if we did require the debuginfo rpm, it still wouldn't >>> get installed automatically. For FC[56], the debuginfo yum >>> repositories are disabled by default. For RHEL[34], the debuginfo >>> RPMs aren't available from a RHN channel, they have to be downloaded >>> separately (from my vague understanding which could be wrong). In >>> addition, debuginfo RPMs are not present on RHEL/FC install media. >>> So, from a current logistical point of view, if the systemtap RPM >>> required the kernel debuginfo RPM, systemtap itself could never be >>> installed because of missing dependencies that could never be met. >>> >>> Currently, using systemtap isn't much different than using gdb. >>> Let's assume that /bin/ls keeps crashing on you for some strange >>> reason that you'd like to debug. You are going to need to >>> download/install the coreutils debuginfo RPM, then use gdb to debug >>> your problem. >>> >> Yea but gdb has other uses then debugging coreutils. SystemTap is >> only used to instrument the kernel. > > > gdb is used to debug user apps. If you compiled the app yourself, > you've got the debuginfo (assuming you compiled with '-g'). If you > are debugging a vendor compiled app, you'll need to download the > associated debuginfo RPM. > > systemtap is used to instrument the kernel. If you compiled your own > kernel, you've got the debuginfo (assuming you compiled with '-g'). > If you are instrumenting a vendor compiled kernel, you'll need to > download the associated debuginfo RPM. > Yes very true. But customers typically don't build their own kernels if they want to stay supportable. I see the issue is: how do we make stap useful to the support engineer? If the tool is not working on the customers system then it will not be used. So how do we insure that stap is working out of the box for all systems? -- David Wilder IBM Linux Technology Center Beaverton, Oregon, USA dwilder@us.ibm.com (503)578-3789