[SCM] systemtap: system-wide probe/trace tool branch, master, updated. rhel52-ga-469-g3559f18

[fche@sourceware.org]

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