This is the mail archive of the systemtap-cvs@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-0.9.5-49-g489afa7


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  489afa702639fd10e9756795bd516d939766247d (commit)
      from  4cc40e829870dd6a1d9714706d38f5fd4b2ec982 (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 489afa702639fd10e9756795bd516d939766247d
Author: Maynard Johnson <maynardj@us.ibm.com>
Date:   Wed Apr 1 09:51:57 2009 -0500

    Fix runtime/itrace.c to call arch_has_*_step() prior to calling utrace_control
    
    As Roland pointed out in his Mar 31 reply to a posting of mine (subject:
    Re: Testing insn.block probe point uncovers possible utrace bug),
    utrace_control() documents that the caller must ensure that
    arch_has_single_step and arch_has_block_step are defined before trying
    to use those step modes.  The attached patch addresses that issue.  I've
    tested this patch on x86_64 arch, and a block step test runs
    successfully, since block step is supported on that arch.  Testing on
    ppc64 arch, the test fails as expected (since block step is not
    supported on ppc64 yet) with:
    	"ERROR: callback for <pid> failed: 1"
    which is sent to stdderr and
    	"usr_itrace_init: arch does not support block step mode"
    which is sent to the system log.
    
    This isn't the most user-friendly way of surfacing an error.  Perhaps
    the stap runtime could have a set of defined return codes that would be
    mapped to strings so the user can get an idea of what the error is
    without looking in the system log.  But that's a side issue, of course.
    
    Regards,
    -Maynard

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

Summary of changes:
 runtime/itrace.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]