fche at redhat dot com | 31 Jul 22:29 2015

[Bug runtime/18751] New: support a STAP_PRINTF(....) macro for use in embedded-C functions

https://sourceware.org/bugzilla/show_bug.cgi?id=18751

            Bug ID: 18751
           Summary: support a STAP_PRINTF(....)  macro for use in
                    embedded-C functions
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

It could be a peer to STAP_ERROR and get implemented in terms of _stp_printf.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.

mcermak at redhat dot com | 29 Jul 20:18 2015

[Bug tapsets/2111] document syscalls tapset

https://sourceware.org/bugzilla/show_bug.cgi?id=2111

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcermak at redhat dot com

--- Comment #10 from Martin Cermak <mcermak at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #5)
> Another important element of finishing this work is to document the syscalls
> tapset in the stapprobes.5 man page.  There is probably no need to
> elaborately
> enumerate all couple of hundred in the man page, but the general conventions
> should be there:
> - what general variables are available ("name", "argstr", ...)
> - what is done for user-space strings, decomposed struct fields

On  Tue  2015-07-21  14:40 , David Smith wrote:                                 
> We've about polished the [nd_]syscall tapsets to a fairly brilliant           
> shine as far as the code goes, but those tapsets aren't documented -             
> PR2111: <https://sourceware.org/bugzilla/show_bug.cgi?id=2111>. Although         
> this sounds a bit boring, there are actually some thinking that needs            
> doing there - like how to handle the nd_syscall probes vs. the syscall           
> probes. We might want to combine the documentation into one set instead          
> of two, but how do you do that cleanly?                                          
>                                                                                  

So this needs parser. Either stap's one, or some external one.                  
So firstly I'll think about how to resuse the former. What's                    
(Continue reading)

fche at redhat dot com | 24 Jul 16:51 2015

[Bug runtime/18714] New: bring back process.statement.absolute probes

https://sourceware.org/bugzilla/show_bug.cgi?id=18714

            Bug ID: 18714
           Summary: bring back   process.statement.absolute probes
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

While inode-uprobes makes $subject probe type not trivially available, we
should still be able to hack around it in the runtime.  Given the requested
virtual address, aat registration time we could walk the process address space,
find the inode & offset corresponding to that address (if any!), and place a
inode+offset uprobe there.  (This doesn't help non-inode gaps in the address
space, alas.)

--

-- 
You are receiving this mail because:
You are the assignee for the bug.

mcermak at redhat dot com | 23 Jul 14:50 2015

[Bug tapsets/18711] New: Pass 4 failure on RHEL7 for examples netfilter_summary and netfilter_drop

https://sourceware.org/bugzilla/show_bug.cgi?id=18711

            Bug ID: 18711
           Summary: Pass 4 failure on RHEL7 for examples netfilter_summary
                    and netfilter_drop
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

Created attachment 8452
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8452&action=edit
netfilter.h differences between 3.10.0-123 and 3.10.0-294

Bug similar to rhbz1055778 now appears again when using systemtap-2.8-6.el7 (or
current upstream 3952632) on top of kernel-3.10.0-294.el7. The error is:

=======
 7.2 S x86_64 #  /usr/bin/stap -g   netfilter_drop.stp TCP 1 -c "sleep 2" 
/tmp/stapBT8dKn/stap_0a103d85fb485e2a1e15b0ad9128aea7_13604_src.c:2507:1:
error: initialization from incompatible pointer type [-Werror]
 .hook = enter_netfilter_probe_0,
 ^
/tmp/stapBT8dKn/stap_0a103d85fb485e2a1e15b0ad9128aea7_13604_src.c:2507:1:
error: (near initialization for ‘netfilter_opts_0.hook’) [-Werror]
(Continue reading)

snehalphule | 23 Jul 07:15 2015
Picon

[PATCH] checks for uprobes in the testsuite sdt_varname.exp


checks for uprobes in the testsuite sdt_varname.exp

Signed-off-by:Snehal Phule <snehal <at> linux.vnet.ibm.com>

---
  testsuite/systemtap.base/sdt_varname.exp |    5 +++++
  1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/testsuite/systemtap.base/sdt_varname.exp b/testsuite/systemtap.base/sdt_varname.exp
index 829f6a0..49a26e2 100644
--- a/testsuite/systemtap.base/sdt_varname.exp
+++ b/testsuite/systemtap.base/sdt_varname.exp
 <at>  <at>  -5,6 +5,11  <at>  <at>  if {![installtest_p]} {
     untested "$test"
     return
  }
+if {![uprobes_p]} {
+   untested "$test"
+   return
+}
+

  # In this testcase, we verify that stap can parse SDT operands of the type
  # [off+]varname[+off][(reg)]. These occur when the operands refer to STB_GLOBAL
--

-- 
1.7.1

dsmith at redhat dot com | 21 Jul 17:01 2015

[Bug translator/18701] New: systemtap can't find $return for sys_fadvise64_64 on rawhide

https://sourceware.org/bugzilla/show_bug.cgi?id=18701

            Bug ID: 18701
           Summary: systemtap can't find $return for sys_fadvise64_64 on
                    rawhide
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
                CC: mjw at redhat dot com
  Target Milestone: ---

On rawhide (4.2.0-0.rc2.git2.1.fc24.x86_64), the syscall testsuite fails
because the syscall tapset has an error in it. The error boils down to not
being able to find $return in kernel.function("sys_fadvise64_64").return:

====
# stap -ve 'probe kernel.function("sys_fadvise64_64").return { print($return)
}'
Pass 1: parsed user script and 109 library script(s) using
243680virt/44816res/7728shr/36980data kb, in 190usr/50sys/239real ms.
semantic error: unresolved target-symbol expression: identifier '$return' at
<input>:1:58
        source: probe kernel.function("sys_fadvise64_64").return {
print($return) }
                                                                         ^
(Continue reading)

Zoltan Kiss | 20 Jul 20:14 2015

Array handling question

Hi,

I have troubles to get what I want from linetimes.stp example, so I've 
decided to create my own somewhat simplified version. I'm currently 
interested in the average runtime of a function after a certain number 
of runs, but apparently it gives me values like 74279383992077, which is 
clearly wrong. And I have a feeling I'm misunderstanding something 
obvious about the array handling, but I couldn't figure out what.
Could anyone give me an advice about what am I missing?

Regards,

Zoltan Kiss

And here is my example script:

global cnt = 0;
global starttime = 0;
global runtimes;

probe process(<procname>).function(<funcname>).call {
         starttime = gettimeofday_ns();
}

probe process(<procname>).function(<funcname>).return {
	runtime = gettimeofday_ns() - starttime;
	starttime = 0;
	runtimes <<< runtime;
	if (cnt > 50000) {
		printf("Runtime avg: %u\n",  <at> avg(runtimes));
(Continue reading)

fche at redhat dot com | 14 Jul 20:53 2015

[Bug translator/18673] New: .statement line-number-range slow for large ranges

https://sourceware.org/bugzilla/show_bug.cgi?id=18673

            Bug ID: 18673
           Summary: .statement line-number-range slow for large ranges
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: fche at redhat dot com
  Target Milestone: ---

We have at least two problems:

- that something like probe FOO.statement("* <at> *:1-99999999")  
  creates a very large linenos[] vector in dwarf_query::parse_function_spec

- and then in dwflpp::iterate_over_srcfile_lines, we iterate over each element
(line number) in collect_lines_for_single_lineno, repeating a large amount of
computation

--

-- 
You are receiving this mail because:
You are the assignee for the bug.

mcermak at redhat dot com | 9 Jul 11:45 2015

[Bug tapsets/18651] New: Possible nd_syscall tapset cleanup based on PR18597 fix

https://sourceware.org/bugzilla/show_bug.cgi?id=18651

            Bug ID: 18651
           Summary: Possible nd_syscall tapset cleanup based on PR18597
                    fix
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

Created attachment 8423
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8423&action=edit
proposed patch

Now, when PR18597 has been fixed, small cleanup can be done in the nd_syscall
tapset. See attached patch.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.

mcermak at redhat dot com | 9 Jul 11:39 2015

[Bug tapsets/18650] New: powerpc variant of longlong_arg() for uprobes swaps the byte order

https://sourceware.org/bugzilla/show_bug.cgi?id=18650

            Bug ID: 18650
           Summary: powerpc variant of longlong_arg() for uprobes swaps
                    the byte order
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

After some testing I came to a conclusion that following change should be done
in tapsets:

=======
$ git diff
diff --git a/tapset/powerpc/registers.stp b/tapset/powerpc/registers.stp
index 1daf5ba..3adcc73 100644
--- a/tapset/powerpc/registers.stp
+++ b/tapset/powerpc/registers.stp
 <at>  <at>  -186,8 +186,8  <at>  <at>  function ulong_arg:long (argnum:long) {

 function longlong_arg:long (argnum:long) {
        if (probing_32bit_app()) {
-               lowbits = _stp_arg2(argnum, 0, 1, 0)
-               highbits = _stp_arg2(argnum+1, 0, 1, 0)
(Continue reading)

mcermak at redhat dot com | 9 Jul 11:28 2015

[Bug tapsets/18649] New: int_arg() misbehaves on x86[_64] for 32-bit uprobe in binary having debuginfo

https://sourceware.org/bugzilla/show_bug.cgi?id=18649

            Bug ID: 18649
           Summary: int_arg() misbehaves on x86[_64] for 32-bit uprobe in
                    binary having debuginfo
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
          Assignee: systemtap at sourceware dot org
          Reporter: mcermak at redhat dot com
  Target Milestone: ---

The int_arg() function doesn't work correctly on i[36]86 and x86_64 when
probing 32-bit userspace application having debuginfo compiled in. Let's have
following program:

=======
int                                                                             
testfc(int arg)                                                                 
{                                                                               
    return arg;                                                                 
}                                                                               

int                                                                             
main()                                                                          
{                                                                               
    testfc(32767);                                                              
(Continue reading)


Gmane