fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
_whitelogger has joined #systemtap
slowfranklin has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 252 seconds]
pwithnall has joined #systemtap
mjw has joined #systemtap
orivej has joined #systemtap
naveen2 has joined #systemtap
naveen1 has quit [Ping timeout: 252 seconds]
naveen4 has joined #systemtap
naveen2 has quit [Ping timeout: 246 seconds]
naveen1 has joined #systemtap
naveen4 has quit [Ping timeout: 246 seconds]
naveen2 has joined #systemtap
naveen1 has quit [Ping timeout: 245 seconds]
naveen3 has joined #systemtap
naveen2 has quit [Ping timeout: 240 seconds]
naveen4 has joined #systemtap
naveen3 has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 240 seconds]
wcohen has joined #systemtap
tromey has joined #systemtap
brolley has joined #systemtap
orivej has joined #systemtap
introom has joined #systemtap
pwithnall has quit [Ping timeout: 252 seconds]
pwithnall has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
mjw has quit [Quit: Leaving]
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 252 seconds]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
pwithnall has quit [Ping timeout: 240 seconds]
slowfranklin has joined #systemtap
<agentzh>
fche: the duplicate func removal optimization pass tends to lead to confusing line numbers in runtime error messages (like read faults). i just wasted 2 hours on such misinfo.
<agentzh>
it's very common for duplicate synthetic functions for primitives like @cast().
<agentzh>
and the read fault error message may point to completely unrelated parts of the user stap script file.
<agentzh>
should we ignore synthetic functions in that optimizer?
tromey has quit [Quit: ERC (IRC client for Emacs 26.1.50)]
wcohen has quit [Ping timeout: 252 seconds]
<fche>
could run code with stap -u ... but a stap -vvv kind of thing will show how many functions are clones of each other
<agentzh>
fche: yeah, that was how i nailed this down.
<agentzh>
but for production uses, the read fault might no longer be reproducible easily.
<agentzh>
so -u is not very helpful for debugging the online errors.
<agentzh>
especially when stap currently gives no backtrace, just a single file name and line number pair.
<agentzh>
unless we always run stap -u online...
<agentzh>
which would be sad.
<agentzh>
maybe the right fix is for the caller to provide source file location info for those synthetic functions.
<agentzh>
so dedup'ing those functions still lead to correct loc info in error messages.
<agentzh>
*leads to
<fche>
not so easy, as the caller may itself be duplicated, and thus may not have correct original-source coordinates
<agentzh>
right.
brolley has left #systemtap [#systemtap]
slowfranklin has quit [Quit: slowfranklin]
<agentzh>
fche: i'd turn off dedeup for synthetic functions in our branch for now. i guess it's not something that will be accepted upstream.
<agentzh>
just a trade-off
slowfranklin has joined #systemtap
<fche>
not sure what's special about synthetic functions for this purpose
<fche>
hm
<agentzh>
because it's very common to have duplicate synthetic functions derived from identical @cast() expressions.
<fche>
perhaps the body-sharing optimization could be conditional on the same token object
<agentzh>
like @cast(p, "foo")
<agentzh>
it can appear very frequently.
<agentzh>
in the same .stp file.
<fche>
yes but we can have identical probe handlers too from wildcards, same thing
<agentzh>
that's much rarer for our use cases... :)
<agentzh>
*at least
slowfranklin has quit [Quit: slowfranklin]
<fche>
for testing, consider extending elaborate.cxx line 4958ish to print the ->tok objects of the original & substitute functiondecl objects
<agentzh>
fche: yeath, that was how i tracked the problem down.
<agentzh>
i'll create a PR to record this issue for now.
<fche>
(there's a typo 'flat' vs 'flag' in there, but whatever)
<agentzh>
v4 for which patch?
<agentzh>
abort?
<fche>
yup, said "abort v4" :-)
<fche>
was a bit too curt with my words though. thanks, go and commit
<agentzh>
oh, sorry, i read it as "about" :P
<agentzh>
great! i'll fix the typo and commit :D
<agentzh>
fche: it seems like -u is less exercised by the users and might expose bugs...just found one.
<agentzh>
*by the user community
<fche>
could be
<agentzh>
will create a PR.
<agentzh>
i have to say stap has accumulated so many features over the years! it's amazing :)
<fche>
re. return-nonvalue-v3 ... here's a glitch
<fche>
stap -p1 -e 'function f() { if (a) return a = 2 }'
<fche>
the keyword-enumerated detection of void-return fails in the sense that a reader can't tell what's what
<fche>
having that list of statement keywords is not that easy to explain, and doesn't stand out visually well
<agentzh>
fche: so i should remove that part?
<fche>
yeah, I think so, both to simplify the code and the explanation. "non-value return only accepted with a ; or } following it"
<fche>
one of the consequences of our loosey grammar, oh well.
<agentzh>
okay, no problems. i'll rework the patch.
<fche>
thanks
<agentzh>
sure
<fche>
for test cases that you need to check only for parseability or non-parseability, you don't need all that .exp material, just add barenaked .stp files under testsuite/parseok vs parseko
<agentzh>
fche: yeah, but those tests are auto-generated so it's actually easier for me :P
<agentzh>
i hope that i can keep that way if you don't mind.
<fche>
ok
<agentzh>
thanks
<fche>
wouldn't be surprised if at some point we extend the .exp machinery to have gcc-like directives embedded in .stp files
<fche>
to reduce the need for .exp files for a few more classes of cases (like expected outputs or diagnostics)
<agentzh>
*nod*
<agentzh>
i'm just not fluent in tcl yet to do that big thing.
<agentzh>
oh you mean embed testing facility directly in the stap language?
<agentzh>
*embedding
<fche>
I mean in tcl
<agentzh>
okay
<fche>
(stap scripts can to some extent self-test, in printf("pass") vs error("fail") e.g.
<fche>
some tests do that
<agentzh>
yeah, inlined assertions.
<agentzh>
luajit does that in most of its official test suite, for example.
<agentzh>
though personally i like comparing output from the outside more :)
<agentzh>
for most of the cases.
<agentzh>
so that it's easier to know the actual output by simply reading the test suite report.
<agentzh>
but i agree inlined assertions could be more advanced to do that automatically.
<agentzh>
luajit's assert() is just like C's, true or false only.
<agentzh>
there is no way other than patching the test script itself to know how different things are in an assert().
<fche>
the stap tapset does in fact have an assert() function