This is the mail archive of the
systemtap-cvs@sourceware.org
mailing list for the systemtap project.
[SCM] systemtap: system-wide probe/trace tool branch, master, updated. rhel52-ga-469-g3559f18
- From: fche at sourceware dot org
- To: systemtap-cvs at sourceware dot org
- Date: 9 Jul 2008 11:20:14 -0000
- Subject: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. rhel52-ga-469-g3559f18
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "systemtap: system-wide probe/trace tool".
The branch, master has been updated
via 3559f184314739bebe527d279d2513ac5124260f (commit)
via a3ee6543b34b773568961e3d48f6ea30e65bc59c (commit)
via 0b8f65798e0b454ccaab1d93925c3e034d4f5624 (commit)
from d99a656a615dd78773316b7ac3972f3f1bcd5fca (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 3559f184314739bebe527d279d2513ac5124260f
Author: Frank Ch. Eigler <fche@elastic.org>
Date: Wed Jul 9 07:14:32 2008 -0400
add changelog entries for last two changes
commit a3ee6543b34b773568961e3d48f6ea30e65bc59c
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Tue Jul 8 12:38:58 2008 -0500
Add test suite for declaration resolution
This adds the test declaration.exp which checks that specific named
declarations inside the kernel both fail and succeed. We get the
failure by only using a single compile unit which is currently known
to have the structure stubbed. We get exactly the same declaration to
succeed by adding a CU that is known to have the declaration.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
commit 0b8f65798e0b454ccaab1d93925c3e034d4f5624
Author: James Bottomley <James dot Bottomley at HansenPartnership dot com>
Date: Tue Jul 8 16:45:16 2008 -0500
Fix semantic error: empty struct
On Tue, 2008-07-08 at 14:57 -0400, Frank Ch. Eigler wrote:
> Hi -
>
> > you need a global cache for resolution ... it's not tied to any local
> > class instance. For class dwflpp it probably doesn't matter, since that
> > class is effectively static (by its survival for a session) but
> > logically because the DW_AT_declaration resolution is global, so should
> > the cache that does it.
>
> .. except it's not actually global, in that the kernel is not the only
> code that will go through the dwarf family of probe processors -
> user-space dwarf files are coming its way soon. Plus, if in the
> future the systemtap frontend attempts distributed probing of multiple
> target systems concurrently, "global" will be even more local.
In that context its as global as a lot of the other static data in that
structure (like this_session) which would also have to be fixed to do a
multiple target system.
Regardless, it can become per instance: it will only screw up if dwflpp
moves to being short lived.
James
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 6 ++
tapsets.cxx | 93 ++++++++++++++++++++++++++++++
testsuite/ChangeLog | 6 ++
testsuite/config/unix.exp | 1 +
testsuite/lib/stap_compile.exp | 39 ++++++++++++
testsuite/systemtap.base/declaration.exp | 19 ++++++
testsuite/systemtap.base/marker.exp | 40 -------------
7 files changed, 164 insertions(+), 40 deletions(-)
create mode 100644 testsuite/lib/stap_compile.exp
create mode 100644 testsuite/systemtap.base/declaration.exp
hooks/post-receive
--
systemtap: system-wide probe/trace tool