fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
mjw has quit [Quit: Leaving]
mjw has joined #systemtap
mjw has quit [Client Quit]
hpt has joined #systemtap
sapatel has quit [Ping timeout: 255 seconds]
sapatel has joined #systemtap
sscox has joined #systemtap
sapatel has quit [Quit: Leaving]
orivej has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
yogananth has joined #systemtap
ChanServ has quit [*.net *.split]
DUKENUKEM has quit [*.net *.split]
xar- has quit [*.net *.split]
darvon has quit [*.net *.split]
fLiPr3VeRsE has quit [*.net *.split]
hpt has quit [*.net *.split]
agentzh has quit [*.net *.split]
ema has quit [*.net *.split]
zodbot has quit [*.net *.split]
jistone has quit [*.net *.split]
gavinguo_ has quit [*.net *.split]
_whitelogger has joined #systemtap
lindi- has joined #systemtap
hpt has quit [Ping timeout: 265 seconds]
tonyj has quit [Remote host closed the connection]
mjw has joined #systemtap
sscox has quit [Ping timeout: 256 seconds]
irker376 has joined #systemtap
<irker376> systemtap: fche systemtap.git:refs/heads/master * release-4.2-49-gffb40c659 / runtime/linux/autoconf-trace-printk.c tapset/linux/logging.stp testsuite/buildok/logging-embedded.stp testsuite/buildok/logging-embedded2.stp: RHBZ1810216: fix ftrace() tapset function related autoconf test http://tinyurl.com/qrnolra
wcohen has quit [Ping timeout: 256 seconds]
tromey has joined #systemtap
beauty has joined #systemtap
<beauty> hello
beauty has quit [Remote host closed the connection]
sscox has joined #systemtap
beauty has joined #systemtap
<beauty> How to use relative path when using process,such as probe process("./a.out") ?
<fche> that works - relative to the cwd of the stap program
<beauty> semantic error: while resolving probe point: identifier 'process' at strobe_variable.stp:4:7
<fche> does that program exist at that location ?
<beauty> but I failed.
<beauty> yeah, it is
<beauty> but when I use full path ,it passed.
<fche> hm, works for me here ... so
<fche> what stap version
<fche> do you have a complete command line
<beauty> Systemtap translator/driver (version 4.0/0.172/0.176, rpm 4.0-10.el7_7)
<beauty> complete command line?
<beauty> probe process("./a.out").function("main@./main.c")
<fche> tried without the @./main.c ?
<beauty> yeah, it passed
<beauty> why
<beauty> so amazing
<fche> my guess is that your a.out program was not compiled in such a way that the compiler saw the path "./main.c"
<fche> maybe it was just "main.c" or something longer
wcohen has joined #systemtap
<beauty> gcc -O0 -g main.c
<fche> and actually the NAME@FILE syntax is for .statement probes
<beauty> I use this compile parameters
<fche> and there NAME@FILE:LINE# is the scheme
<beauty> Yeah, I first use statement
<beauty> When I met error, I use functions.
<beauty> And statement also failed if using func@./main.c
<fche> next time try using wildcards in your .statement probe, or stap -L 'process("./a.out").statement("*")' e.g.
<beauty> I want probe spectial file
<beauty> so "func@file path" must keep file path is full?
<fche> function("name") is the proper syntax
<fche> or statement("name@file:line") where many components can be wildcarded
beauty has quit [Ping timeout: 260 seconds]
beauty has joined #systemtap
<beauty> sorry, just now I offline
<beauty> so the file path in statement must be full path?
beauty95 has joined #systemtap
<beauty95> Sorry, just now I'm offline.
<beauty95> So the file path in statement must use full path?
<fche> that can use wildcards too
<fche> use stap -L (list) to see the data as stap recovers it from the debuginfo and your wildcards
<beauty95> Yeah, I know that can use wildcards
<beauty95> I want to know whether must use full path in statement(fun@file:line)
<fche> generally no
<beauty95> beause the full path is too long and not relative for portability
<fche> try using the basename, and/or a partial wildcard
<beauty95> So what should I do to if using relative path in statement
<beauty95> what is basename?
<fche> see [man basename]
<fche> "what should I do" - use whatever works. stap will try to match up a partial name against the ones recorded in the debuginfo by the compiler
<fche> stap -L is a good way of seeing those full names,
<fche> you can then try writing wildcards or basename abbreviations in the stap code
amerey has joined #systemtap
<beauty95> thank you
<beauty95> I have another question
<beauty95> stap -e 'global steps; probe process("/bin/ls").insn {steps++}
<beauty95> semantic error: while resolving probe point: identifier 'process' at <input>:1:21
<fche> yes, kernels more modern than rhel6 era don't support this unfortunately
<beauty95> don't support ".instn" ????
<fche> correct.
<beauty95> oh..
<beauty95> So what's the difference between statement("*") and ".instn"?
<beauty95> It seems the same.
<fche> statement operates at source level statement boundaries
<fche> insn operates (operated) at the machine instruction boundaries
<fche> statements are generally much larger than instructions
<beauty95> It seems insn is aimed at assembly
<beauty95> statement is aimed at source code.
<fche> yes, and it's broad/nonspecific
<fche> and yes
<beauty95> It seems insn is more accurate
<fche> they are different
<beauty95> which is more close to perf instruction ?
<beauty95> insn?
<fche> perf doesn't do anything down at the instruction level ... it can sample periodically and it can trace intermittently
<fche> but not down at the insn level
<beauty95> Yeah, I know thi.
<beauty95> this
<beauty95> If I use probe every instruction and count using insn or statement("*") by systemtap. Are these values close to perf instruction?
<fche> if you just want to -count- instructions, use a performance counter type widget; stap exposes these to some extent
<fche> probing instructions or statements is more than counting, it's stopping & inspecting & resuming
<beauty95> ol
khaled has joined #systemtap
<beauty95> systemtap will record more instructions than the probed program? The extra instructions is used and generated by systemtap.
<beauty95> right?
<fche> not sure what you mean by 'record'
<beauty95> I mean that more instruction will be printed when probed by systemtap that the program's actual instructions when not probed by systemtap.
<beauty95> the second that is "than"
<fche> printed by what software?
<beauty95> stap -e 'global steps; probe process("/bin/ls").insn {steps++} probe end {printf("Total instructions: %d\n", steps);}' -c /bin/ls
<beauty95> this "printf"
<beauty95> total instructions
<fche> ok
<fche> in that case, the number of instructions executed under .insn probing (on a capable kernel) should be right about the actual number of instructions executed by that process (in userspace)
<beauty95> yeah, the perf sample instructions is the same as the actual number of instructions
<beauty95> I have tested it.
<beauty95> So the systemtap and perf is the same.
<beauty95> result.
<fche> well they measure things very differently, but in this particular case should have comparable results
<beauty95> Year, I will test it.
<beauty95> When using process("PATH").mark("LABEL"), I just insert "STAP_PROBE(xxx,"LABEL")" in the special source code position and compile as normal. right?
<fche> pretty much
sapatel has joined #systemtap
beauty95 has quit [Ping timeout: 260 seconds]
Amy1 has joined #systemtap
<Amy1> I am offline just now
<fche> no you're not :)
<Amy1> I am beauty
<fche> i am vomit
<Amy1> lol
<Amy1> so is it right?
beauty30 has joined #systemtap
<beauty30> STAP_PROBE1(0,"xx",1);
<beauty30> semantic error: while resolving probe point: identifier 'process' at strobe_variable.stp:6:7
<fche> use ordinary symbols for the first and second parameters
<fche> i.e,
<fche> STAP_PROBE1(beauty30,xx,1);
<fche> and again listing with wildcards is useful: stap -L 'process("a.out").mark("*")'
beauty30 has quit [Ping timeout: 260 seconds]
<Amy1> cool. it passed
<Amy1> than you very much.
<fche> very good
<Amy1> Almost every question has solved.
<fche> I have not solved the life-universe-everything problem JUST YET
<Amy1> I spent a week to learn stap.
<fche> hey glad you did!
<fche> hope it helps you
<Amy1> It's sure.
<Amy1> It's so easy to learn even much easier than vb. :)
<fche> now that's scary
<Amy1> why :)
<Amy1> my god.
mjw has quit [Ping timeout: 256 seconds]
mjw has joined #systemtap
tonyj has joined #systemtap
beauty has quit [Quit: Connection closed for inactivity]
beauty has joined #systemtap
<beauty> I know systemtap many years ago.
<beauty> This week I learned it.
<beauty> cool.
<fche> if you find it successful - or even unsuccessful - at helping with your problems, we'd love to hear
<beauty> so great
<beauty> bpf is developing nowadays
<beauty> how about bpf, fche
<fche> stap --bpf exists as an optional backend - many limitations (inherited from kernel bpf rules)
<fche> but you can try simple things - on new kernels & new systemtap at least
<beauty> ebpf
<beauty> many conferences have it
<fche> yes, we know :)
<beauty> fche, could you show me some performance stp.
<beauty> useful and popular
<beauty> yeah, I know this
mjw has quit [Quit: Leaving]
mjw has joined #systemtap
mjw has quit [Quit: Leaving]
sscox has quit [Ping timeout: 240 seconds]
sscox has joined #systemtap
orivej has joined #systemtap
beauty has quit [Quit: Connection closed for inactivity]
mjw has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
khaled has quit [Quit: Konversation terminated!]
orivej has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
orivej has quit [Ping timeout: 260 seconds]
sscox has quit [Ping timeout: 258 seconds]
wcohen has quit [Ping timeout: 256 seconds]
mjw has quit [Quit: Leaving]
amerey has quit [Quit: Leaving]
irker376 has quit [Quit: transmission timeout]
gromero has joined #systemtap
wcohen has joined #systemtap