fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<fche>
yeah that looks good
<agentzh>
cool, i'll prepare a formal patch with tests then.
<agentzh>
fche: btw, it seems that stap does not support the al register?
<agentzh>
(of x86)
<agentzh>
we could add that?
<agentzh>
though we could always use bit op on ax or eax, but builtin support for al/bh/etc can still be handy :)
<fche>
no strong opinion on that
<agentzh>
hmm, seems like the x86_64 register tapset func does not really support 16-bit registers it seems. it always reads 32-bit from those 16-bit registers like ax.
<agentzh>
is it deserved fixing?
* agentzh
is using stap to probe assembly programs.
orivej has joined #systemtap
slowfranklin has joined #systemtap
slowfranklin has quit [Client Quit]
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
naveen4 has quit [Quit: WeeChat 1.9.1]
naveen has joined #systemtap
orivej has quit [Ping timeout: 252 seconds]
mjw has joined #systemtap
mjw has quit [Quit: Leaving]
slowfranklin has joined #systemtap
mjw has joined #systemtap
orivej has joined #systemtap
pwithnall has joined #systemtap
ericlee has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #systemtap
brolley has joined #systemtap
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #systemtap
tromey has joined #systemtap
orivej has quit [Ping timeout: 252 seconds]
mjw has quit [Quit: Leaving]
slowfranklin has quit [Quit: slowfranklin]
pwithnall has quit [Read error: Connection reset by peer]
pwithnall has joined #systemtap
pwithnall has quit [Ping timeout: 252 seconds]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
slowfranklin has quit [Ping timeout: 245 seconds]
<agentzh>
is there a web page detailing how to subscribe to the systemtap mailing list? googling does not reveal anything helpful, it seems.
<agentzh>
i re-added the original tests but to check syntax errors.
<fche>
ok
<fche>
ya know, there is a dejagnu library proc for running a stap script and comparing its output
<fche>
so maybe your test cases don't have to be quite so wordy
<agentzh>
yeah, we could add a proc to testsuite/lib/ to abstract certain common parts.
<agentzh>
it's just that it's the most flexible way for my test generator :)
<agentzh>
so it can now be committed? ;)
<fche>
sure
<agentzh>
awesome.
<agentzh>
fche: do you mind adding a resusable proc to testsuite/lib? if not, i can prepare a patch.
<fche>
there may already be one
<fche>
the stap_run* series
<agentzh>
i was aware of those but unfortunately they do not work for my purposes.
<agentzh>
i need to test stdout, stderr, and exit code separately.
<fche>
sure, a new proc then
<fche>
the less boilerplate in our files, the better
<agentzh>
i understand.
<agentzh>
should i name it stap_run4?
<fche>
if you like
<agentzh>
it's a horrible name though.
<fche>
make it a better name
<agentzh>
i'll think about it.
<agentzh>
after having the new proc, i'll update all my tests to use it.
<agentzh>
they were generated by my tool anyway.
<fche>
yup
<agentzh>
how about [stap_run_ok cmd exp_out exp_out_is_regex exp_stderr exp_stderr_is_regex exp_exit_code] ?
<agentzh>
the exp_out_is_regex and exp_stderr_is_regex are boolean values.
<fche>
stap_run_regexps ?
<agentzh>
oh, sorry, exp_exit_code is not needed for stap_run_ok.
<agentzh>
if we could also have a stap_run_nok proc
<agentzh>
or maybe we could simply check whether the exit code is zero or not.
<agentzh>
none of my existing tests actually check the non-zero exit code's actual values anyway.
<agentzh>
the problem with stap_run_regex is that we could have literal exp_stdout but regex exp_stderr (or the other way around)
<agentzh>
or we could introduce several procs for different combinations just like stap runtime's map_set_is/map_set_ss and etc?
<agentzh>
like run_stap_rs_ok or run_stap_sr_ok?
<agentzh>
or run_stap_rr_ok
<fche>
rs?
<agentzh>
rs == regex string
<agentzh>
or rl == regex literal if you like it better...
<agentzh>
personally i like separate boolean args better.
<agentzh>
it's easier to remember
<agentzh>
and easier to implement.
<fche>
or 'regex' :)
<agentzh>
'regex' for which part?
<fche>
proc name
<fche>
no need to abbreviate so much that it becomes a mystery
<agentzh>
you mean something like run_stap_ok_regex_str ?
<agentzh>
or even run_stap_ok_rx_str ?
<agentzh>
rx is a common regex abbrev i think.
<agentzh>
or rx_lit
<agentzh>
for regex stdout pattern and literal stderr pattern
<agentzh>
similarly, we can have run_stap_nok_lit_rx and etc.
<agentzh>
nok is a bit confusing.
<agentzh>
it could mean the stdout pattern should not match...hmmm
<agentzh>
not good.
<agentzh>
or maybe we should provide separate pros for running stap and checking stdout/stderr/exit code?
<agentzh>
so that we do not have squeeze all the combinations into a single poor proc :)
<agentzh>
*have to
<fche>
your choice, think about it
<fche>
don't feel pressured to make the proc names super compact
<fche>
and don't feel pressured to make only one super parametrized proc, if more specialized procs make sense
<agentzh>
just [run_stap4 stdin stdout stderr exit_code] and then [like stderr stderr_regex "$desc"] [is stdout exp_stdout_literal "$desc"] ?
<agentzh>
now run_stap4 is a nifty name since it outputs 4 things.
<agentzh>
oh, i missed the input arg, cmd, as the first arg.
<agentzh>
should be [run_stap4 cmd stdin stdout stderr exit_code]
<agentzh>
the names "like" and "is" are from perl's testing world. if you think they are too short, maybe we could name them "like_ok", "is_ok", and etc.
<agentzh>
but i really like "like", "unlike", "is", "isnt", "ok", and "nok" subs in the perl testing world.
<agentzh>
very handy.
<agentzh>
i'll work out a patch in the next couple of hours if you like this design.