16:53 <agentzh> fche: okay. please let me know if there's anything i can do to move it forward. thanks!

16:54 <agentzh> fche: for another thing, what do you think of allowing multiple -x PID options for stap to allow probing multiple specified user processes?

16:54 <agentzh> in the multi-target case, the target() func is no longer sufficient. and i'm thinking about introducing a new is-target() func that directly returns true or false. what's your opinion?

16:55 <agentzh> when tracing multi-process daemons like nginx and httpd, it is often desired to trace all their worker processes at once.

16:56 <agentzh> i've been hard-coding pid values inside my stap scripts, which is not desired since the ko needs to be recompiled everytime the target pids change.

16:57 <agentzh> sorry, i think is_target() insteasd of is-target() :)

16:57 <agentzh> *i mean

16:57 <fche2> we've dealt a little bit with process hierarchies at the tapset level

16:58 <agentzh> will you be a bit more specific please?

16:59 <agentzh> you mean fetching all direct child processes' pids given a parent ppid?

17:01 <agentzh> if we want to trace all direct children, then this will do the trick, but still sometimes we just want to probe *some* of the processes. ideally, we could handle an aribitrary set of pids instead of assuming process hierarchies.

17:02 <agentzh> i hope we can have a nice way for the most general cases.

17:05 <fche2> yeah, I see your point with -x PID -x PID

17:05 <agentzh> great

17:06 <fche2> I was referring to target_set_pid()

17:06 <fche2> that tracks child processes too, but does not directly influence whether uprobes are placed

17:18 <agentzh> yeah, that's useful for certain use cases.

17:54 <fche2> re. @vma(). is there some reason that needs to be a builtin operator, as opposed to a normal tapset function ?

18:20 <fche2> agentzh, there are some nits but overall I still am ok with the @vma code. You can commit it. Please tighten up the NEWS to be shorter, and add @vma() to the man page, a useful example script would be great in systemtap.examples, if not too hard

18:21 <fche2> typeresolution_info::visit_atvma_op probably doesn't need all that clog traffic, just the semantic-error

18:22 <fche2> creating a test for it could use command line parameters ($1 et.) as @var() parameters, fed by some `nm ... | grep | awk ` pipeline to feed addresses

18:23 <fche2> it'd be nice if that test-oriented $^foo template processor widget were not the only effective way to use this

18:24 <agentzh> fche2: re builtin operator vs tapset func: because a good amount of work can be done at compile-time, especially for non-PIE cases.

18:24 <agentzh> tapset is more runtime-oriented.

18:24 <fche2> yeah finding the relocation basis

18:25 <agentzh> re clog: yeah, i can remove them. it was just very useful for my debugging and development.

18:25 <agentzh> so i thought i (or other developers) might want to enable them again.

18:25 <fche2> ideally when we throw a semantic error, we should produce good enough diagnostics that this wouldn't be needed

18:26 <fche2> but yeah ok, verbose > 2 is fine

18:26 <agentzh> yeah, will do.

18:34 <agentzh> re test cases using cmdline args, sure, i'll add one.

18:35 <agentzh> i'll think about the example script, but probably in a seperate commit since it would take some more time.

18:36 <fche2> I'd hope that the facility can demonstrate its usefulness with a sample, if we want to encourage people to use it.

18:36 <agentzh> i also found some compatibility issues on ubuntu 16.04 in the tests, and i've already addressed them in my local copy.

18:36 <agentzh> *local tree

18:38 <agentzh> fche2: yeah, it makes sense. it is for dwarfless probing, so i need to think of a small and standalone example that may look useful immediately.

18:42 <agentzh> fche2: how about just writing a blog post for this new feature? i can do that quickly. it's easier than writing a self-contained example :P

18:42 <agentzh> and i can put some examples into the blog post.

19:04 <fche2> ok

22:18 <agentzh> seems like execname() might return a relative file paths (when the target process is invoked that way), is there a recommended way in stap to check an absolute exec file path?

22:19 <agentzh> basically i'd like to filter out all processes from a particular executable file path in probes like timer.profile. the pids cannot be determined since those processes are short-lived.