Message-ID: <4AB98BD2.2030002@redhat.com>
Date:	Tue, 22 Sep 2009 19:45:38 -0700
From:	Josh Stone <jistone@...hat.com>
To:	SystemTap <systemtap@...rceware.org>
CC:	LKML <linux-kernel@...r.kernel.org>, LWN <lwn@....net>
Subject: SystemTap 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@...ot/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("*@...E: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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists