public inbox for systemtap-cvs@sourceware.org
help / color / mirror / Atom feed
From: jistone@sourceware.org
To: systemtap-cvs@sourceware.org
Subject: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.3-66-g785cf26
Date: Fri, 20 Aug 2010 07:24:00 -0000	[thread overview]
Message-ID: <20100820072439.24699.qmail@sourceware.org> (raw)

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  785cf26dc2120b1d47c42a85fd8cd29d7481d41c (commit)
       via  626d0de72e6882ff0ec015c8c728e6d9aaaa590b (commit)
       via  5ee00816648f564f541811657d894e0be8e970dc (commit)
       via  fde50242adbeee67cb93ab6b887ddb824f87f7c9 (commit)
       via  d48bc7eb832b818d2a4043e7a02c1d13fdf3f6b7 (commit)
       via  4ef356968e9f7406e6fc324d5010fa9d66bcfce7 (commit)
       via  f5958c8f368ffab013222116bb42f4c0ee969252 (commit)
      from  8c67c3379b9be66d977a70e09f121997f5d85a19 (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 785cf26dc2120b1d47c42a85fd8cd29d7481d41c
Author: Josh Stone <jistone@redhat.com>
Date:   Fri Aug 20 00:18:37 2010 -0700

    Kill a stray paren in examples/io/inodewatch2.stp

commit 626d0de72e6882ff0ec015c8c728e6d9aaaa590b
Author: Josh Stone <jistone@redhat.com>
Date:   Fri Aug 20 00:18:03 2010 -0700

    Support a slight 32/64-bit difference in semok/mangled.stp

commit 5ee00816648f564f541811657d894e0be8e970dc
Author: Josh Stone <jistone@redhat.com>
Date:   Fri Aug 20 00:16:55 2010 -0700

    Add shebang to buildok/syscalls-arch-detailed.stp

commit fde50242adbeee67cb93ab6b887ddb824f87f7c9
Author: Josh Stone <jistone@redhat.com>
Date:   Thu Aug 19 17:15:06 2010 -0700

    Print nicer placeholders for aggregates in $$vars et al.
    
    * tapsets.cxx (dwarf_var_expanding_visitor::visit_target_symbol_context):
      Use {...} and [...] to indicate aggregate types.

commit d48bc7eb832b818d2a4043e7a02c1d13fdf3f6b7
Author: Josh Stone <jistone@redhat.com>
Date:   Thu Aug 19 16:06:23 2010 -0700

    Include variables from containing scopes in $$vars too
    
    We now iterate through the lexical scopes up to but not including the
    file level, so we can print variables in containing scopes too.
    
    * tapsets.cxx * (dwarf_var_expanding_visitor::visit_target_symbol_context):
      Iterate through scopes to find available vars.

commit 4ef356968e9f7406e6fc324d5010fa9d66bcfce7
Author: Josh Stone <jistone@redhat.com>
Date:   Thu Aug 19 15:42:55 2010 -0700

    List variables from containing scopes too
    
    Now we iterate through the lexical scopes up to but not including the
    file level, so we can find variables in containing scopes too.  This is
    most significant for statement probes to list everything available.
    Excluding file-level means that globals aren't listed, but we could
    consider a more verbose version to include those too.
    
    * tapsets.cxx (dwarf_derived_probe::saveargs): Iterate through scopes.

commit f5958c8f368ffab013222116bb42f4c0ee969252
Author: Josh Stone <jistone@redhat.com>
Date:   Thu Aug 19 14:32:09 2010 -0700

    Resolve statement scopes lexically instead of by raw PC
    
    When we have a statement PC within a function that we wish to probe,
    it's not reliable to use getscopes(PC) for variable scoping.  This is
    because there may also be inline instances at the PC, and so you can end
    up in a different scope altogether.
    
    So now we can traverse the DIEs within a function looking for the
    innermost containing the PC, avoiding those nested DIEs which are
    actually inlines.  This also lets us get rid of the hack that made
    function prologues do a PC search, so we should have more reliable
    scoping all around.
    
    * dwflpp.cxx (dwflpp::inner_die_containing_pc): New, scan lexical scopes
      for the innermost DIE that contains a PC, avoiding inlines.
      (dwflpp::iterate_over_labels): Use the above to find the lexical scope
      containing the label's address.
    * tapsets.cxx (query_srcfile_line): Use the above to find the closest
      DIE for each statement probe.
      (dwarf_var_expanding_visitor::getscopes): Always call getscopes on the
      given scope_die, so we don't have the trouble that a PC search entails.

-----------------------------------------------------------------------

Summary of changes:
 dwflpp.cxx                                      |   48 ++++-
 dwflpp.h                                        |    2 +
 tapsets.cxx                                     |  275 +++++++++++++----------
 testsuite/buildok/syscalls-arch-detailed.stp    |    1 +
 testsuite/semok/mangled.stp                     |    2 +-
 testsuite/systemtap.examples/io/inodewatch2.stp |    2 +-
 6 files changed, 203 insertions(+), 127 deletions(-)


hooks/post-receive
--
systemtap: system-wide probe/trace tool


                 reply	other threads:[~2010-08-20  7:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100820072439.24699.qmail@sourceware.org \
    --to=jistone@sourceware.org \
    --cc=systemtap-cvs@sourceware.org \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).