fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
cbzx has quit [Ping timeout: 272 seconds]
bchrisman has joined #systemtap
cbzx has joined #systemtap
hpt has quit [Ping timeout: 256 seconds]
hpt has joined #systemtap
cbzx has quit [Ping timeout: 240 seconds]
bchrisman has quit [Quit: Leaving.]
hpt has quit [Ping timeout: 272 seconds]
zw01 has quit [Ping timeout: 250 seconds]
wakatana2 has left #systemtap [#systemtap]
zw01 has joined #systemtap
Meths has quit [Ping timeout: 250 seconds]
Meths has joined #systemtap
nkambo has joined #systemtap
sadmac has quit [Ping timeout: 250 seconds]
sadmac has joined #systemtap
ego has joined #systemtap
ananth has joined #systemtap
srikar_away is now known as srikar
bchrisman has joined #systemtap
Humble has joined #systemtap
naveen has joined #systemtap
cbzx has joined #systemtap
cbzx has quit [Ping timeout: 272 seconds]
bchrisman1 has joined #systemtap
bchrisman has quit [Ping timeout: 250 seconds]
Meths_ has joined #systemtap
Meths has quit [Ping timeout: 272 seconds]
srikar is now known as srikar_away
ego has quit [Ping timeout: 240 seconds]
srikar_away is now known as srikar
ananth has quit [Ping timeout: 250 seconds]
ananth has joined #systemtap
naveen has quit [Quit: Leaving.]
naveen has joined #systemtap
mjw has joined #systemtap
ego has joined #systemtap
srikar is now known as srikar_away
srikar_away is now known as srikar
naveen1 has joined #systemtap
naveen has quit [Quit: Leaving.]
lberk has quit [Ping timeout: 260 seconds]
modem has joined #systemtap
ego has quit [Ping timeout: 240 seconds]
scox has quit [Ping timeout: 250 seconds]
ananth has quit [Ping timeout: 240 seconds]
cbzx has joined #systemtap
Meths_ has quit [Ping timeout: 240 seconds]
Meths has joined #systemtap
naveen1 has quit [Quit: Leaving.]
cbzx has quit [Ping timeout: 256 seconds]
pfallenop has quit [Ping timeout: 245 seconds]
ego has joined #systemtap
hchiramm has joined #systemtap
pfallenop has joined #systemtap
pfallenop has quit [Remote host closed the connection]
pfallenop has joined #systemtap
wcohen has quit [Remote host closed the connection]
vbernat has quit [Remote host closed the connection]
vbernat has joined #systemtap
srikar is now known as srikar_away
cbzx has joined #systemtap
cbzx has quit [Ping timeout: 240 seconds]
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
srikar_away is now known as srikar
cbzx has joined #systemtap
wcohen has joined #systemtap
drsmith has joined #systemtap
lberk has joined #systemtap
cbzx has quit [Quit: Konversation terminated!]
scox has joined #systemtap
naveen1 has joined #systemtap
cbzx has joined #systemtap
cbzx has quit [Ping timeout: 240 seconds]
brolley has joined #systemtap
ego has quit [Quit: Leaving]
modem has quit [Ping timeout: 256 seconds]
sfink has joined #systemtap
naveen1 has quit [Quit: Leaving.]
cbzx has joined #systemtap
srikar is now known as srikar_away
lorddoskias1 has joined #systemtap
<lorddoskias1>
hello, if my probe relies on a datastructure which is defined inside a .c file of the kernel (concretely i'm talking about struct mapped_device, defined in drivers/md/dm.c) how should I get access to it? Since currently systemtap complains that it can't resolve the type ?
<jistone>
lorddoskias, what is the probe context? in the same .c file?
<jistone>
lorddoskias, and how are you trying to access the type?
<jistone>
(would help to see a small code snippet of what you want to do)
mbenitez has quit [Quit: To office]
flu has quit [Quit: Leaving]
flu has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
<lorddoskias1>
jistone: i will give to you in a minute
<lorddoskias1>
jistone: here is my probe: probe module("dm_thin_pool").statement("__pool_destroy@drivers/md/dm-thin.c:2807") {
<jistone>
ok I see, so this is in dm-thin.c, and struct mapped_device is only found in dm.c
<lorddoskias1>
yes
<jistone>
@cast(..., "kernel<drivers/md/dm.c") tries to compile that file to make our own debuginfo; useful only for headers really
<lorddoskias1>
also if i want md to point to the string that the -name member is how do i do that? right now i get a mismatch that md is inferred to be long
<lorddoskias1>
jistone: so is there a way to access the mapped_device struct?
<jistone>
how about just @cast(..., "kernel") ?
<jistone>
that should read the kernel's existing debuginfo
<jistone>
for reading the name, use kernel_string()
<jistone>
maybe kernel_string_n() since this buffer is known 16 bytes (is it always 0-terminated?)
<lorddoskias1>
i guess so
<lorddoskias1>
jistone: it seems to have worked, i will now try to trigger the probe :)
<jistone>
great
<lorddoskias1>
one more question - when i probe a particular function is there a way to filter my probe only if the caller to the function is a particular function? I mean can I do that in the probe's definition or in the body i need to use caller() symname() etc to implement this logic on my own?
<fche>
that's one way
<fche>
one can also use probe ....function("bar").callee("foo").call depending on gcc version, call style etc.
<lorddoskias1>
right i remember seeing something like that in the docs but couldn't verifiy it
<fche>
see also man stapprobes
<lorddoskias1>
jistone: so your advice worked, thanks :)
<jistone>
you're welcome
<lorddoskias1>
yet another question: what is the correct way to proceed when I have N server, each running the same kernel but I want to have the kernel sources only on 1 machine, and use that for developing/compiling my systemtap scripts and only run them on those N server. As a first requirement I need a systemtap-runtime installed
<lorddoskias1>
and then do I se the remote server functionality to compile scripts or can I develop on a different machine with the same kernel and then distribute some (binary?) module/stap script?
<jistone>
either way is possible
<jistone>
use a compile server, or manually run to -p4 and distribute that .ko yourself to use with staprun
<jistone>
there's also stap --remote; from the compile server, it can ssh into others to copy and run the module for you, and collect all output back to you
<fche>
(and see also stap --remote=$HOST for remote execution)
<jistone>
stap --remote can fanout to multiple hosts (but I'm not sure how high N can scale well in practice)