public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: David Smith <dsmith@redhat.com>
To: David Wilder <dwilder@us.ibm.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	ken@odtv.com,         "'Badari Pulavarty'" <pbadari@gmail.com>,
	systemtap@sources.redhat.com
Subject: Re: Anyone tried SystemTap with the latest RHEL5 Beta refresh
Date: Wed, 01 Nov 2006 19:07:00 -0000	[thread overview]
Message-ID: <4548EC3C.9080800@redhat.com> (raw)
In-Reply-To: <4548EA74.7000105@us.ibm.com>

David Wilder wrote:
> David Smith wrote:
> 
>> David Wilder wrote:
>>
>>> Frank Ch. Eigler wrote:
>>>
>>>> "Ken Robson" <ken@odtv.com> 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.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

  parent reply	other threads:[~2006-11-01 18:51 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-26 20:43 Nguyen, Thang P
2006-10-27  0:39 ` Li Guanglei
2006-10-27 20:25 ` Badari Pulavarty
2006-10-27 21:48   ` Frank Ch. Eigler
2006-10-30 18:28     ` Vara Prasad
2006-10-30 18:33       ` Frank Ch. Eigler
2006-10-31 23:15         ` Vara Prasad
2006-11-01  1:37           ` Tim Bird
2006-11-01  2:13           ` Frank Ch. Eigler
2006-11-01  6:51             ` Gerrit Huizenga
2006-11-01  8:56             ` Ken Robson
2006-11-01 12:40               ` Frank Ch. Eigler
2006-11-01 17:20                 ` David Wilder
2006-11-01 18:06                   ` David Smith
2006-11-01 18:12                     ` David Wilder
2006-11-01 18:23                       ` Frank Ch. Eigler
2006-11-01 18:27                         ` David Wilder
2006-11-01 19:31                           ` Frank Ch. Eigler
2006-11-01 19:07                       ` David Smith [this message]
2006-11-01 19:09                         ` David Wilder
2006-11-01 19:54                         ` Vara Prasad
2006-11-01 20:39                     ` Michael K. Dolan Jr.
2006-11-01 20:40                     ` Michael K. Dolan Jr.
2006-11-01 20:04             ` Vara Prasad
2006-11-01 21:11               ` Keshavamurthy, Anil S
2006-11-01 21:36                 ` Badari Pulavarty
2006-11-01 23:47           ` William Cohen
2006-11-02 19:09             ` Badari Pulavarty
2006-11-02 19:18               ` Frank Ch. Eigler
2006-11-02 23:53                 ` David Boreham
2006-11-02 23:55                 ` Badari Pulavarty
2006-11-03  0:35                   ` David Boreham
2006-11-03  2:22                   ` Frank Ch. Eigler
  -- strict thread matches above, loose matches on Subject: below --
2006-11-01 18:51 Stone, Joshua I
2006-10-27 21:05 Nguyen, Thang P
2006-10-26 18:28 Vara Prasad
2006-10-26 20:39 ` Mike Mason
2006-10-26 22:09 ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4548EC3C.9080800@redhat.com \
    --to=dsmith@redhat.com \
    --cc=dwilder@us.ibm.com \
    --cc=fche@redhat.com \
    --cc=ken@odtv.com \
    --cc=pbadari@gmail.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).