headers
Frank Ch. Eigler | 1 Nov 2006 02:37
Picon
Favicon
Gravatar

Re: Anyone tried SystemTap with the latest RHEL5 Beta refresh

Hi -

> fche wrote:
> [...]
> >Unfortunately, other customers prefer that systemtap's loose
> >dependencies (particularly, the kernel-debuginfo) not be installed by
> >default, even if they choose an "install everything" option at the
> >anaconda screens.  [..]

varap wrote:

> O.k, before i think of a way to satisfy both the needs i need to 
> understand the objection of the other group.

> The objection of other customers to not to install debuginfo package is 
> it because of wasted disk space due to large size of debuginfo package 
> or time to install or something else.

All those, plus the manual way in which RHEL debuginfo packages are at
present published.

> I am assuming kernel debuginfo is considered a dependency for
> SystemTap, am I right?

It is a loose dependency, in that the RPM does not list it as such
(any more), and that it is theoretically possible to run some scripts
without kprobes, and thus without dwarf data.

> What is the point of installing a package that doesn't work due to
> lack of dependencies?
(Continue reading)

Permalink | Reply | 17 comments |
headers
Frank Ch. Eigler | 1 Nov 2006 03:13
Picon
Favicon
Gravatar

offline elfutils processing committed

Hi -

A big commit went in just now, as a holloween prank no doubt.  Some
dude named "fche" finally checked in code to switch to elfutils'
"offline" processing mode, which allows generation of instrumentation
for kernels where the specific list of modules and their addresses
need not be known until run-time.  This involves a somewhat longer
elaboration pass, since all possibly-needed modules' dwarf data are
brought in, not just those that are loaded right now on the
translator's host.

This part needs one more bit of code from staprun (hunt) to pass a
module/section/address table to the module.  A limited mockup is
present in the generated code and should be replaced shortly.
(dwarf_derived_probe_group::emit_module_decls).

The new code also significantly improves the code generated for
scripts involving many probes.  (It also drastically simplifies the
translator's own code for this.  Partly unraveling this mess took lots
of time.)  All this builds on but replaces the earlier "probe groups"
effort.  You may find first-time compile time for complex scripts to
be noticeably shorter.  Since it is compatible with the recent caching
code, second-time compile time is near-zero.

Just to finally commit this piece of work, I just disabled some
previously working but little-used code.  I'll plop them back in
shortly: the benchmarking option, and perfmon/mark based probes.

- FChE
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gui,Jian | 1 Nov 2006 05:47
Picon
Favicon

Re: [PATCH][kprobe]disallow kprobes on emulate_step function

> Please add that and feel free to post the patch to linuxppc-dev
> for upstream inclusion.
 >
Thanks. sent out.
Permalink | Reply | 0 comments |
headers
Gerrit Huizenga | 1 Nov 2006 06:38
Picon
Favicon

Re: Anyone tried SystemTap with the latest RHEL5 Beta refresh


On Tue, 31 Oct 2006 20:37:34 EST, "Frank Ch. Eigler" wrote:
> Hi -
> 
> > fche wrote:
> > [...]
> > >Unfortunately, other customers prefer that systemtap's loose
> > >dependencies (particularly, the kernel-debuginfo) not be installed by
> > >default, even if they choose an "install everything" option at the
> > >anaconda screens.  [..]
> 
> varap wrote:
> 
> > O.k, before i think of a way to satisfy both the needs i need to
> > understand the objection of the other group.
> 
> > The objection of other customers to not to install debuginfo package is
> > it because of wasted disk space due to large size of debuginfo package
> > or time to install or something else.
> 
> All those, plus the manual way in which RHEL debuginfo packages are at
> present published.
> 
> > I am assuming kernel debuginfo is considered a dependency for
> > SystemTap, am I right?
> 
> It is a loose dependency, in that the RPM does not list it as such
> (any more), and that it is theoretically possible to run some scripts
> without kprobes, and thus without dwarf data.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexandre Oliva | 1 Nov 2006 07:50
Picon
Favicon

Re: "no match" semantic error for some existing probe points

On Oct 30, 2006, Roland McGrath <roland <at> redhat.com> wrote:

>> <2><4673b>: Abbrev Number: 49 (DW_TAG_inlined_subroutine)
>> DW_AT_abstract_origin: <467d3>
>> DW_AT_low_pc      : 0x9db0
>> DW_AT_high_pc     : 0x9de8
>> DW_AT_call_file   : 0
>> DW_AT_call_line   : 0
>> 
>> Does this mean the compiler didn't produce such information and
>> we cannot handle this in systemtap?

> This indeed is the compiler giving us no useful information here.

Indeed, but this is an inlined call of ptrace_disabled.  What we're
missing is info about the clear_single_step() inlined call.  However,
in my kernel source tree, clear_single_step is a macro, not a
function, so you won't get debug info for it without -g3 and, even
then, you may not get any line numbers whatsoever for the function
that does nothing but call a macro.

I'm going to need preprocessed sources, a compilation command line and
a compiler version number in order to try to get more detailed info
and fix the compiler bug, if there is one.

Ideally, such info should be in a Systemtap bug report at
sources.redhat.com or bugzilla.redhat.com.

Thanks,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ken Robson | 1 Nov 2006 08:03

RE: Anyone tried SystemTap with the latest RHEL5 Beta refresh

> varap wrote:
> > fche wrote:
> > [...]
> > >Unfortunately, other customers prefer that systemtap's loose
> > >dependencies (particularly, the kernel-debuginfo) not be 
> installed by
> > >default, even if they choose an "install everything" option at the
> > >anaconda screens.  [..]
> 
> > O.k, before i think of a way to satisfy both the needs i need to 
> > understand the objection of the other group.
> 
> > The objection of other customers to not to install 
> debuginfo package is 
> > it because of wasted disk space due to large size of 
> debuginfo package 
> > or time to install or something else.
> 
> All those, plus the manual way in which RHEL debuginfo packages are at
> present published.
> 
> > I am assuming kernel debuginfo is considered a dependency for
> > SystemTap, am I right?
> 
> It is a loose dependency, in that the RPM does not list it as such
> (any more), and that it is theoretically possible to run some scripts
> without kprobes, and thus without dwarf data.
> 
> > What is the point of installing a package that doesn't work due to
> > lack of dependencies?
(Continue reading)

Permalink | Reply | 12 comments |
headers
guij at cn dot ibm dot com | 1 Nov 2006 09:56
Favicon

[Bug translator/3441] New: "no match" semantic error for some existing probe points

See thread:
http://sourceware.org/ml/systemtap/2006-q4/msg00145.html

I've updated my kernel to 2.6.18.1, and things are same.

Test environment:
RHEL4U4, 2.6.18.1, elfutils-0.123-0.1, systemtap-20061101

root:/usr/src/linux-2.6.18.1>gcc -v
Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-redhat-linux
--build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)

root:/usr/src/linux-2.6.18.1>uname -a
Linux localhost.localdomain 2.6.18.1 #1 SMP Wed Nov 1 01:26:54 EST 2006 ppc64
ppc64 ppc64 GNU/Linux

--

-- 
           Summary: "no match" semantic error for some existing probe points
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
(Continue reading)

Permalink | Reply | 1 comment |
headers
guij at cn dot ibm dot com | 1 Nov 2006 10:14
Favicon

[Bug translator/3441] "no match" semantic error for some existing probe points


------- Additional Comments From guij at cn dot ibm dot com  2006-11-01 09:14 -------
Created an attachment (id=1397)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1397&action=view)
preprocessed file and compilation script of ptrace.c

In the attachment:
ptrace.i:   the preprocessed file of ptrace.c
compile.sh: the commandline generating ptrace.o from ptrace.i
ptrace.c:   the original file in linux-2.6.18.1/arch/powerpc/kernel/
ptrace.o, debug_line: pre-built files for your convenience

The compilation command shown by "Make V=1" is:
gcc -m64 -Wp,-MD,arch/powerpc/kernel/.ptrace.o.d  -nostdinc -isystem
/usr/lib/gcc/ppc64-redhat-linux/3.4.6/include -D__KERNEL__ -Iinclude  -include
include/linux/autoconf.h  -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Os -msoft-float -pipe -mminimal-toc
-mtraceback=none  -mcall-aixdesc -mtune=power4 -mno-altivec -funit-at-a-time
-mstring -Wa,-maltivec -fomit-frame-pointer -g	-Wdeclaration-after-statement 
-mno-minimal-toc   -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ptrace)" 
-D"KBUILD_MODNAME=KBUILD_STR(ptrace)" -c -o arch/powerpc/kernel/.tmp_ptrace.o
arch/powerpc/kernel/ptrace.c

"gcc -v" shows:
Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=ppc64-redhat-linux
--build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gui,Jian | 1 Nov 2006 10:42
Picon
Favicon

Re: "no match" semantic error for some existing probe points

Alexandre Oliva wrote:
> Indeed, but this is an inlined call of ptrace_disabled.  What we're
> missing is info about the clear_single_step() inlined call.  However,
> in my kernel source tree, clear_single_step is a macro, not a
> function, so you won't get debug info for it without -g3 and, even
> then, you may not get any line numbers whatsoever for the function
> that does nothing but call a macro.
In 2.6.18.1, clear_single_step is defined as an inlined call in
arch/powerpc/kernel/ptrace.c (ppc64) or
arch/powerpc/kernel/ptrace.c (ppc32). Although it is also defined
as macro in arch/powerpc/kernel/traps.c, I think ptrace_disable is
using its inlined call definition.

> 
> I'm going to need preprocessed sources, a compilation command line and
> a compiler version number in order to try to get more detailed info
> and fix the compiler bug, if there is one.
> 
> Ideally, such info should be in a Systemtap bug report at
> sources.redhat.com or bugzilla.redhat.com.
> 
Thanks. I've opened bug 3441 for this and attached some data.
http://sourceware.org/bugzilla/show_bug.cgi?id=3441

Please let me know if more info is needed.

-Guijian
Permalink | Reply | 2 comments |
headers
Frank Ch. Eigler | 1 Nov 2006 13:32
Picon
Favicon
Gravatar

Re: Anyone tried SystemTap with the latest RHEL5 Beta refresh

"Ken Robson" <ken <at> 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
Permalink | Reply | 11 comments |

Gmane