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>
the gist of it is that this stuff is implemented in terms of stap functions that use @cast() to decode libpython internal data structure
<serhei>
right
<fche>
that is a problem because @cast() inside functions MUST be accompanied by a module-name
<fche>
and that module-name is not the same module as the probe/context that is invoking the function
<fche>
and that module-name list is some goofy handcrafted string that is a sign of design failure :)
<fche>
ok so if you like, think on it for a bit see how you'd solve it
<fche>
I have an idea
<fche>
but I'll keep it to myself for the next 120 seconds :)
<serhei>
gotcha
<serhei>
cue jeopardy theme
<fche>
yup
* serhei
sees manual "If you do not specify the module parameter, the translator defaults to either the probe module for dwarf probes or to kernel for functions and all other probe types."
<serhei>
I suppose the question is whether it makes sense for functions to inherit this decision. But clearly it didn't when the functionality was first designed
<fche>
what choice is there
<serhei>
having a module list in @cast sort of solves this by maintaining a list of hardcoded paths instead of one hardcoded path
<serhei>
fine as long as libpython really does live under /usr/lib64
<fche>
yeah but even then there's no guarantee that the right version is used
<fche>
one could have python3.6 and python3.7 libraries; be invoked from a python3.6 binary, and @cast hits the 3.7 debuginfo
<serhei>
basically have to have @cast check what we're actually probing
<serhei>
I'm guessing that means a function has to run different casting code when called from different probes, which is one reason it wasn't implemented like this originally
<serhei>
would have been a bunch of extra work with (at the time) no clear use case for it
<serhei>
still, I think the resulting code amounts to a switch statement among finite possibilities for what the module could be
<serhei>
thoughts?
<fche>
yeah, nice
<fche>
so yeah, I think we're getting some arguments that allowing functions to make context-sensitive operations like @cast() - heck or $var - would be a definite user convenience.
<fche>
that means functions need context
<fche>
that means function translation becoming forked by context
<serhei>
could be 'forked by context' in the sense of becoming separate functions (like with the overloading support) or in the sense of generating translations that produce a switch statement that looks at the context struct
<serhei>
not sure yet which is the better option
<fche>
yeah. it can be all translate-time work, with no runtime switch
<serhei>
probably
<serhei>
the number of different contexts is finite, so
<serhei>
func () { ... } => funcblah_overload14_context15 () { ... } is a totally feasible option
<serhei>
hmm
<serhei>
yeah, feasible. I'm not sure if we can have sources of context divergence that start to multiply
<serhei>
not for @cast since the probed module is the same for every non-explicitly-specified cast
<serhei>
in a probe
<fche>
I don't think they can multiply
<fche>
it'd be at most 1 variant per probe point
<fche>
and can prune based on the static call graph (which we know)
<serhei>
yeap
<serhei>
will need to decide how error reporting looks
<serhei>
e.g. a cast that's ok for one module might be wrong for a different module
<fche>
error will robinson
<serhei>
... if that's the case might need some phrasing like "incorrect @cast operation ... when called from probe ..."
<serhei>
not a technical challenge, just a bikeshedding point
<serhei>
which I think should be yellow
<fche>
goldenrod
<fche>
clearly
<fche>
was my official xsetroot -solid background color back in the 90s
<serhei>
but what if the cyclists are color blind
<serhei>
then it needs polka dots or maybe a stripe pattern to be more recognizable
<fche>
so good news --- that's along the ways I was thinking, so will do
<fche>
so bad news --- the ease at which you came up with the equivalent idea means it was pretty foreseeable :-) OR that we are both brilliant :--)
<serhei>
foreseeable is good when fixing things
* serhei
tries xsetroot -solid goldenrod
<serhei>
it is 90s
<fche>
doesn't work for me any more :(
<serhei>
to me it screams 'fill up screen with useful things QUICKLY' :)
<fche>
catvideo.gif
sscox has quit [Quit: sscox]
sscox has joined #systemtap
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
khaled has quit [Remote host closed the connection]
<Guest8010>
I want use embeded C to call kernel code: usb_for_each_dev(), for each usb device, this function will call a call back, the callback need to be a pure C. int get_usb_dev(struct usb_device *dev, void *p), then I want to
<Guest8010>
save each dev to associate array!
<fche>
something like that might work
<fche>
but var is still not typed
<fche>
print(var) doesn't let stap know what type var has
<fche>
maybe you could do global var = 0; to indicate that it's a numeric scalar
<fche>
that's not an associative array; that'd require a different initialization or usage
<fche>
(and different STAP_GLOBAL_.... operation)
<Guest8010>
ok, my first step is save one to var, even with global var = 0x0; I still got error: implicit declaration of function ‘STAP_GLOBAL_SET_var’
<fche>
hmmm think that should work
<fche>
oh wait
<fche>
no
<fche>
that pragma only works in embedded-C FUNCTIONS
<fche>
your static int ditty is fully unparsed
<fche>
and there won't be enough context in an arbitrary static function like that for the STAP_GLOBAL_* thing to work, even if it were defined
<fche>
so you'd have to do the iteration somehow within the get_all_usb_dev() embedded-c function
<fche>
and in there you can call STAP_GLOBAL_* etc.
<fche>
(and put the pragma there too)
<fche>
dunno mmmaybe it could work as a C nested function, ewww careful with that, might not work.
<Guest8010>
Thanks, lots of info, let me try
<Guest8010>
so, that pragma will not work in pure C function, right?
<fche>
right
<fche>
the translator doesn't know what that block is; it could be just some #include's
<Guest8010>
This makes can't call some useful kernel API from systemtap, such as usb_for_each_dev,
<Guest8010>
I tried both way, 1. implement iteration in my own, but internally it calls other functions, such as next_device.
<Guest8010>
2. tried to pass a hybird embedded C, something like this, as callback of usb_for_each_dev, global var;function get_usb_dev: long (dev: long, p: long) %{ /* pragma:write:var*/ STAP_GLOBAL_SET_var(dev); return 0;%}
<Guest8010>
but it wouldn't work, it would be great if later version can support something like this
<Guest8010>
Another question! print(@cast(0xffffffff8820d640, "bus_type")$$); works. I got hex address: $ sudo cat /proc/kallsyms | grep usb_bus_typeffffffff8820d640 D usb_bus_type
<Guest8010>
but print(@cast(0x000000001ca7013c, "usb_device")$$); not work, I got the hex address using printk
<fche>
the struct name must be correct
<fche>
that address looks pretty fishy btw
<Guest8010>
Yes, the struct name is correct, the address looks fishy, I got from printk, here is my code, I use dmesg, then got hex value, then hardcoding it here https://pastebin.com/9gSppDYj
<fche>
printk addresses are sometimes disguised
<Guest8010>
oh, I had to change %p to %lx, in prink,
<Guest8010>
now I got something like this, 0xffff9c039b605000, and pretty print works!
<agentzh>
i've run all my local tests and it seems fine.
<agentzh>
including some stress testing on read hardware.
orivej has quit [Ping timeout: 258 seconds]
<fche>
ok, the runtime parts are fine
<fche>
I wonder about that dump_stack() bit.....
<agentzh>
that's irrelevant.
<agentzh>
please ignore it.
<agentzh>
but maybe we can have something like that as well?
<fche>
what function is that calling?
<agentzh>
in case the builtin unwinder is broken?
<fche>
if that's a kernel function ... it doesnt' need those pragmas
<fche>
and the builtin unwinder falls back to kernel facilities if the unwinder fails
<agentzh>
okay, i can remove them.
<fche>
anyway let's deal with that completely separately
<agentzh>
sure.
<fche>
it may need a /* guru */ or such marker if the thing is not known/provably safe in all probe contexts
<agentzh>
right, just like the existing printk wrapper.
<agentzh>
re and the builtin unwinder falls back to kernel facilities if the unwinder fails
<agentzh>
is it already implenented in stap?
<agentzh>
i could still only get the top frame when using print_backtrace() or sprint_backtrace().
<agentzh>
dump_stack() gives me perfect backtraces.
<fche>
sent where?
<agentzh>
print_backtrace() sends to staprun's stdout?
<agentzh>
dump_stack() sends to dmesg.
<fche>
yeah so it's not a substitute.
<fche>
but there is logic to do some of that
<agentzh>
yeah, sure. i mean stealing its code, not reusing the API as is.
<agentzh>
for a quick workaround, dump_stack() still has its place in the std tapset, maybe?
<agentzh>
just like printk which is already included.
<agentzh>
i can make it a separate commit if you don't mind.
<fche>
definitely separate commit
<agentzh>
thanks
<fche>
note that printk() is marked as /* guru */
<agentzh>
for the vmalloc change, we'll do more real world testing in the wild.
<agentzh>
just to make sure.
<agentzh>
yeah, i already noted the guru bit.
<agentzh>
i've already being using it myself and it requires -g.
<agentzh>
thanks for the reminder.
<agentzh>
will update my patch accordingly.
<fche>
consider adding the same * sfunction etc. docs as per printk()
<agentzh>
sure, will do.
<agentzh>
the existing form is merely for a quick peek. not for committing.
<agentzh>
and will also update Changes file.
<agentzh>
since it's a new API.
<agentzh>
still haven't got the time to dig up the print_backtrace quirk.
<agentzh>
will do that later.
<agentzh>
oh, btw, remember anothing. currently stap's backtraces use virtual memory addresses for each func frame, which is not very useful for DSO.
<fche>
not very useful how?
<agentzh>
i wonder if we can simply provide the offset, so that it can be fed into tools like addr2line directly.
<fche>
virtual addresses are the real native ones seen by the program
<agentzh>
for instance, strace's backtrace use relative addresses directly.
<agentzh>
sure, virtual addresses do provide more info but it's just not very convenient since we have to grab the base address separately and do the maths every time.
<agentzh>
we prepared our own patches to add new APIs to output relative addresses directly.
<agentzh>
just wondering if stap official has any interest here.
<agentzh>
we can live with our own patches if there's no interest in the mainline.
<agentzh>
fche: so it's fine to commit the kmalloc -> vzalloc patch to the mainline?
<fche>
yeah
<agentzh>
thanks
<agentzh>
will do
<agentzh>
this way we can have more people testing this change.
<agentzh>
with this patch, we no longer see any kmalloc allocaitions larger than 4KB.
<agentzh>
with a stap module tracing stap modules :)
<agentzh>
fche: do we need to mention the kmalloc change in NEWS?