This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RFC: ideas for release notes for the next release
- From: David Smith <dsmith at redhat dot com>
- To: Systemtap List <systemtap at sources dot redhat dot com>
- Date: Wed, 22 Apr 2009 15:12:23 -0500
- Subject: RFC: ideas for release notes for the next release
Hi,
We wanted to push out a new (0.9.6?) release this week. Below are
some suggestions for the release notes. Please read through them and
suggest additions/fixes.
The systemtap team announces release 0.9.XXX.
= Where to get it
http://sourceware.org/systemtap/ - our project page
http://sourceware.org/systemtap/ftp/releases/systemtap-0.9.XXX.tar.gz
git commit release-0.9.XXX
= 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
- The --skip-badvars option now also suppresses run-time error
messages that would otherwise result from erroneous memory accesses.
Such accesses can originate from $context expressions fueled by
erroneous debug data, or by kernel_{long,string,...}() tapset calls.
For a full overview of the stap frontend see man stap(1).
= Systemtap script language changes
- @cast can now determine its type information using an explicit header
specification. For example:
@cast(tv, "timeval", "<sys/time.h>")->tv_sec
@cast(task, "task_struct", "kernel<linux/sched.h>")->tgid
- The overlapping process.* tapsets are now separated. Those probe
points documented in stapprobes(3stap) remain the same. Those that
were formerly in stapprobes.process(3stap) have been renamed to
kprocess, to reflect their kernel perspective on processes.
- New probes 'kprobe.function(FUNCTION)' and
'kprobe.function(FUNCTION).return' for dwarfless probing. These
postpone function address resolution to run-time and use the
kprobe symbol-resolution mechanism. Probing of absolute statements
can be done using the kprobe.statement(ADDRESS).absolute construct.
= Code contributors for this release
Ananth N Mavinakayanahalli, Andre Detsch, David Smith, Eugene Teo,
Eugeniy Meshcheryakov, Frank Ch. Eigler, Jim Keniston, Josh Stone,
Kent Sebastian, Mark Wielaard, Masami Hiramatsu, Maynard Johnson,
Prerna Saxena, Roland McGrath, Stan Cox, Sunzen Wang, Tim Moore,
Wenji Huang, William Cohen
= Examples of tested kernel versions
2.6.9-70 (el4/i386)
2.6.18 (el5/ia64/i686/x86_64-xen)
2.6.27.21 (f10/i686/x86_64)
2.6.29 (i586/x86_64)
= Know issues with this release
Some kernel crashes continue to be reported when a script probes
broad kernel function wildcards.
Some 2.6.28- and 2.6.29-era kernels contain bugs that can more
easily trigger crashes upon systemtap scripts. Upgrade to the
latest -stable or -rc if possible.
= Problems resolved for this release
PR10055 generate dummy modules w/types for @cast
PR10078 uretprobes on functions returning structs/unions
PR7072 use _stp_reserve_bytes for printf buffer
PR9953 split up the two process.* tapsets
PR10070 don't warn about side-effect-free probes in -t (timing)
mode
PR10067 fix bitfield access when used with @cast
PR10049 restore better errors for $return
PR9940 avoid double calling of uprobes in shared libraries
PR10026 read marker/tracepoint args directly
PR10037 add target_symbol token to $context error messages
PR5163 assign need_uprobes during pass-2
PR10032 trigger cleanup after relay thread errors
PR6580 implement symname, symdata and modname context functions
PR9995 test for [installtest_p] && [utrace_p].
PR10019 add --skip-badvars to suppress run-time memory errors too
PR4105 support up to 9 (up from 5) array index dimensions
PR10016 purge stap of all pgrp and system() usage
PR10020 sys_sigaltstack param change
PR10016 run stap in its own process group with waiter process for
signals
PR9998 adapt tapset/i686/registers.stp to latest kernel
= 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 500-600 passes and a small handful of
failures.
--
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)