lkml.org 
[lkml]   [2009]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSystemTap release 1.0
The SystemTap team announces release 1.0.

experimental support for unprivileged users, cross-compiling for
foreign architectures, matching C++ class and namespace scopes,
reduced runtime memory consumption, reduced dormant overhead in
userspace markers, bug fixes, and more...

= Where to get it

http://sourceware.org/systemtap/ - our project page
http://sourceware.org/systemtap/ftp/releases/systemtap-1.0.tar.gz
http://koji.fedoraproject.org/koji/packageinfo?packageID=615
git tag release-1.0 (commit 6a7aa1a1)

= How to build it

See the README and NEWS files at
http://sourceware.org/git/?p=systemtap.git;a=tree
Further information at http://sourceware.org/systemtap/wiki/

= SystemTap frontend (stap) changes

- There is now EXPERIMENTAL support for unprivileged users. Such users
are restricted to only probes and tapset functions that have been
explicitly deemed safe. See the NEWS file for more information on the
restrictions and how to enable this feature.

- It is now possible to cross-compile systemtap scripts for foreign
architectures, using the new '-a ARCH' and '-B OPT=VALUE' flags. For
example, put arm-linux-gcc etc. into your $PATH, and point systemtap
at the target kernel build tree with:
stap -a arm -B CROSS_COMPILE=arm-linux- -r /build/tree [...]
The -B option is passed to kbuild make. -r identifies the already
configured/built kernel tree and -a its architecture (kbuild's
ARCH=...). Systemtap will infer -p4.

- stap-start-server now accepts the -r, -R, -I, -B and -a options in
order to start a cross compiling server. The server will correctly
advertise itself with respect to the kernel release and architecture
that it compiles for.

- When specified on stap-client, the -r and -a options will be
considered when searching for a suitable server.

- Support output file switching by SIGUSR2. Users can command running
stapio to switch output file by sending SIGUSR2.

- Memory consumption for scripts involving many uprobes has been
dramatically reduced.

- The systemtap notion of "architecture" now matches the kernel's,
rather than that of "uname -m". This means that 32-bit i386 family
are all known as "i386" rather than "i386" or "i686"; "ppc64" as
"powerpc"; "s390x" as "s390", and so on. This is consistent between
the new "-a ARCH" flag and the script-level %( arch ... %)
conditional.

- A new experimental transport mechanism, using ftrace's ring_buffer,
has been added. This may become the default transport mechanism in
future versions of systemtap. To test this new transport mechanism,
define 'STP_USE_RING_BUFFER'.

- Support for recognizing DW_OP_{stack,implicit}_value DWARF expressions
as emitted by GCC 4.5.

= SystemTap script language changes

- The function spec for dwarf probes now supports C++ scopes, so you can
limit the probes to specific namespaces or classes. Multiple scopes
can be specified, and they will be matched progressively outward.
probe process("foo").function("std::vector<*>::*") { }
probe process("foo").function("::global_function") { }

- The preprocessor now supports || and && in the conditions.
e.g. %( arch == "x86_64" || arch == "ia64" %: ... %)

- It is now possible to define multiple probe aliases with the same
name. A probe will expand to all matching aliases.
probe foo = bar { }
probe foo = baz { }
probe foo { } # expands twice, once to bar and once to baz

= SystemTap tapset changes

- process().mark() probes now use an enabling semaphore to reduce the
computation overhead of dormant probes.

- Many functions have been marked for use by unprivileged users. The
general rule is that the functions must only return information that
is either globally available or specific to one's own processes.

- The netdev tapset has many new probe points for monitoring network
traffic and device configurations.

- The function task_backtrace returns the current hex backtrace of any
arbitrary task in the system.

- The function is_myproc returns whether the current process is owned by
the same user that launched the systemtap script.

= New script examples

- general/badname.stp Bad filename filter
- memory/mmanonpage.stp Track VM system actions on anonymous pages
- memory/mmfilepage.stp Track VM system actions on file-backed pages
- memory/mmreclaim.stp Track VM system page reclamation
- memory/mmwriteback.stp Track VM system writing to disk
- network/netdev.stp Trace activity on network devices

= Contributors for this release

Breno Leitao, Dave Brolley, David Smith, Eugeniy Meshcheryakov,
Frank Ch. Eigler, Jim Keniston, Josh Stone, Maran Pakkirisamy,
Mark Wielaard, Masami Hiramatsu, Przemysław Pawełczyk, Robb Romans,
Roland McGrath, Stan Cox, Tim Moore, Wenji Huang, William Cohen

= Examples of tested kernel versions

2.6.9 (el4/i686)
2.6.18 (el5/ia64/i686/x86_64)
2.6.27.30 (f10/i686/x86_64)
2.6.30.5 (f11/i686/x86_64)
2.6.31 (f12/i686/x86_64)

= Known issues with this release

- When using the systemtap client and server udp port 5353 must be open
in your firewall in order for the clent to find servers using
avahi-browse.

- Some kernel crashes continue to be reported when a script probes broad
kernel function wildcards.

= Bugs fixed for this release

2475 Inlines don't match filenames correctly
4186 cross-architecture compilation
4541 systemtap.stress/current.stp fails to build on ia64
5679 inline documentation for scripts/tapsets
6866 Extend stp_symbol_snprintf for user space
6905 process("a").statement("main@/root/a.c:*") fails
10084 dropwatch fails on kernels without kfree_skb tracepoint
10155 Switching output files by signal
10204 Place userspace markers in systemtap itself
10294 .statement("*@FILE:NNN-MMM") line-range probes broken
10301 adding '?' to the end of a probe results in a script failure
10408 IA-32 - stap unable to decode parameter location using DWARF
10417 Support DW_OP_{implicit,stack}_value
10424 All tracepoints are unusable if any one header is bad
10467 Failure in source:line matching aborts further searching
10486 raise default MAXSTRINGLEN on 64-bit hosts
10491 Compilation error on running para-callgraph.stp ia64/s390
10495 Allow multiple, same name, probe point alias alternatives
10499 Missing @file:line info from resolved probes
10506 uprobes.ko load broken by module-signing checks
10507 overhuge BSS for many-uprobe module
10509 Compilation error on systems not having NSS support
10512 STAP_PROBES don't work in c++ constructors/destructors
10521 Add support for DECLARE_TRACE_WITH_CALLBACK
10524 oversize DATA for uprobe-intensive scripts
10533 inlined vars are not always found
10537 process().function().label() doesn't select multiple inlines
10538 Handle anonymous structs and unions nicer
10539 ioblktime.stp fails in s390x
10543 cache cleaning with cache_mb_limit=0 cleans up new module
10544 buildrun.cxx "Error %d ..." messages uninformative
10551 pax/grsecurity linux/module.h build compatibility
10552 document '-M' (bulk merge) flag
10568 translator issue with tapsets
10572 stap misses functions with the same name in one CU
10573 Identical inline instances may be probed from multiple CUs
10574 Some functions resolve to pc=0x0
10589 runtime _stp_{dbug,warn,err} should not use _stp_vscnprinf
10594 Cache dwarf iterations to improve translator speed
10602 REG_IP() used as lvalue fails on s390x, probably ia64
10604 new memory examples fail when mm_* tracepoints unavailable.
10605 Unknown symbol in module error (Unknown symbol si_swapinfo)
10608 don't attempt 32-bit syscall tests without 32-bit devel env.
10613 32-bit statfs [ustat] test fails on 2.6.30 kernels
10617 make "make uninstall" work
10618 Unable to find member 'nr_sectors' for struct request
10642 improve performance of .return saved-$variable translation

= Test results on various systems

- After running "sudo make installcheck" from the test suite, on a
suitably equipped machine (kernel debugging data and other stuff
installed), you should see 1000-1100 passes and a small handful of
failures.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-09-23 04:47    [W:0.035 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site