fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
cbzx has quit [Ping timeout: 240 seconds]
drsmith has left #systemtap [#systemtap]
cbzx has joined #systemtap
hpt has joined #systemtap
cbzx has quit [Ping timeout: 240 seconds]
brolley has joined #systemtap
brolley has left #systemtap [#systemtap]
wakatana2 has left #systemtap [#systemtap]
sfink has quit [Ping timeout: 240 seconds]
bchrisman has quit [Read error: Connection reset by peer]
wmealing has joined #systemtap
bchrisman has joined #systemtap
<wmealing>
if one does something similar to this
<wmealing>
stap -L 'kernel.function("vfs_read")'
<wmealing>
i dont get back the local vars at that point
<fche>
looking at the debuginfo, some location data is available for some of those variables, but not at the entry pc
<fche>
it might be worthwhile adding that to the BZ (incl. readelf -w dump of the .ko.debug); the compiler folks like to see preprocessed source + gcc command line, but that's not trivially available
<fche>
try a statement probe by source file:line
<fche>
see also [man error::dwarf]
<wmealing>
righto
<wmealing>
this will be the first time ive done that
<fche>
yeah
<wmealing>
this would be module.statement(""fuse_fill_write_pages@fs/fuse/file.c:955")
<fche>
I'd use a line range to see what works
<wmealing>
or prod the line directly that i'm intrested in
<wmealing>
ok
<fche>
... but on your box I'm having trouble having any of them
<fche>
(the line directly would be ideal)
<wmealing>
please ignore the exploits in /root .. they are not there.
cbzx has quit [Read error: Connection reset by peer]
naveen has joined #systemtap
ego has joined #systemtap
srikar_away is now known as srikar
nkambo has quit [Ping timeout: 250 seconds]
nkambo has joined #systemtap
nkambo has quit [Ping timeout: 240 seconds]
nkambo has joined #systemtap
ananth has quit [Ping timeout: 272 seconds]
lorddoskias has left #systemtap [#systemtap]
ananth has joined #systemtap
naveen has quit [Ping timeout: 272 seconds]
irker248 has quit [Quit: transmission timeout]
naveen has joined #systemtap
<wmealing>
fche: still awake ?
<wmealing>
i had an idea
<wmealing>
and i wanted to run it past you
mjw has quit [Quit: Leaving]
naveen has quit [Ping timeout: 272 seconds]
ego has quit [Ping timeout: 240 seconds]
naveen has joined #systemtap
hpt has quit [Ping timeout: 256 seconds]
ananth has quit [Quit: Leaving]
hpt has joined #systemtap
ego has joined #systemtap
hpt has quit [Ping timeout: 250 seconds]
mjw has joined #systemtap
cbzx has joined #systemtap
pfallenop has quit [Ping timeout: 240 seconds]
ego has quit [Ping timeout: 250 seconds]
pfallenop has joined #systemtap
drsmith has joined #systemtap
cbzx has quit [Ping timeout: 256 seconds]
ego has joined #systemtap
pfallenop has quit [Remote host closed the connection]
pfalleno1 has joined #systemtap
ego has quit [Ping timeout: 272 seconds]
wcohen has quit [Ping timeout: 240 seconds]
lorddoskias has joined #systemtap
<lorddoskias>
if i set a probe on return to a function, do i have access to the local variables defined in the function? (provided that they are defined at the top of the function and not some inner block)? since stap -L doesn't show the local variables
ego has joined #systemtap
groleo has quit [Quit: Leaving.]
<mjw>
lorddoskias, no, because when the return probe hits you already left the function.
<lorddoskias>
right, so i jus tplaced a .statement probe
<mjw>
yes, that should work
<lorddoskias>
and how can I use defines from .h files or enums for example?
<lorddoskias>
because right now i'm using the raw numbers of the define? does gcc preserve such debug information?
<lorddoskias>
ls
ego has quit [Ping timeout: 256 seconds]
<mjw>
gcc might preserve some if using -g3, but stap won't see the defines. Maybe it should. But you can use "guru mode" -g and include the .h file to get access to them sometimes.
nkambo has quit [Ping timeout: 272 seconds]
<lorddoskias>
mjw: which part of the documentation discusses this aspect e.g. referring to c defines within stp script?
<mjw>
I don't immediately know.
<mjw>
You can find some examples in some of the standard tapsets e.g. syscalls_aux.stp
<mjw>
but those are all kernel related
<mjw>
it might actually not be that easy for user space...
<lorddoskias>
i'm interested in kernelspace in fact
<lorddoskias>
cool. will check this out
wcohen has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
jlebon has quit [Ping timeout: 245 seconds]
jlebon has joined #systemtap
srikar is now known as srikar_away
srikar_away is now known as srikar
tromey has joined #systemtap
brolley has joined #systemtap
srikar is now known as srikar_away
srikar_away is now known as srikar
fLiPr3VeRsE has quit [Quit: Lost terminal]
lzap has quit [Ping timeout: 260 seconds]
<lorddoskias>
i've setup a probe like so: probe kernel.statement("sys_umount@fs/namespace.c:1626") {
<lorddoskias>
if ($retval != 0) {
<lorddoskias>
printf("Failed due to first check\n");
<lorddoskias>
if ($path->dentry != $path->mnt->mnt_root) {
<lorddoskias>
printf("Failed due to mount being locked\n");
lzap has joined #systemtap
<lorddoskias>
} else {
<lorddoskias>
} else if ($mnt->mnt->mnt_flags & 0x800000) {
<lorddoskias>
printf("Failed due to check_mnt\n");
<lorddoskias>
}
<lorddoskias>
}
<lorddoskias>
}
<lorddoskias>
and when i run my stap script it says: semantic error: unable to find local 'retval', [man error::dwarf] dieoffset 0x189d6e8 in kernel, near pc 0xffffffff811c34bf in SyS_umount fs/namespace.c (alternatives: $ret, $name, $flags)): identifier '$retval' at loop.stp:43:6
<lorddoskias>
source: if ($retval != 0) {
<lorddoskias>
but retval is defined inside sys_umount in fs/namespace.c
<fche>
the compiler may have nuked that variable at that location
<lorddoskias>
;\
<fche>
perhaps try a range of line numbers in the vicitinity
<fche>
or use a .return probe
<lorddoskias>
but with the return probe i won't have access to the local variables necessary to perform the inner checks
<fche>
$path and $mnt?
<lorddoskias>
yep
<fche>
you could have two cooperating probes; one to save $path/$mnt, and another one to process $return later
<lorddoskias>
yeah, i thought of that just now :). basically stick them in global variables
<fche>
yup, that's what they're for
<fche>
(index them with [tid()])
<lorddoskias>
i see
<lorddoskias>
cool, thanks, will have a go at that. Still plenty of tricks to learn
<fche>
yeah
<fche>
we work in an imperfectly debuginfo'd world :)
Humble has quit [Ping timeout: 272 seconds]
<fche>
or have you considered probing do_umount instead ?
<fche>
or is the code jumping over that in your scenario?
<lorddoskias>
already did, my failure doesn't go there, i.e. it fails in sys_umount
Humble has joined #systemtap
<lorddoskias>
rather the failure I'm after happens in sys_umount
fLiPr3VeRsE has joined #systemtap
<fche>
considered line-by-line tracing the function?