14:16 <lorddoskias1> does systemtap have a way to log to dmesg?

14:16 <lorddoskias1> e.g. a function which would do that?

14:19 <flu_> lorddoskias1, you can try the printk tapset function in tapset/linux/logging.stp

14:20 <lorddoskias1> right, thanks

16:21 <gila> lorddoskias1 there is also the system action (or exec.. cant recall) so you could logger(1M)

16:21 <gila> that should read call logger

16:23 <fche> yup, those are the two easiest ways

16:23 <fche> printk() is not safe from all contexts (thus marked with /* guru */ )

16:24 <fche> system(sprint("/usr/bin/logger %s", message)) is safe (but will be a bit delayed)

17:25 <p53ud0nym> Is "$ret" a predefined keyword? I have the variable "ret" that I woudl like to change. How would I specify the varible ret instead of the SysTap return value?

17:28 <fche> p53ud0nym, see [man stapprobes] for the types of $variables available

17:29 <fche> changing $ret should work fine; I'm not sure what you mean by 'systemtap return value'

18:37 <p53ud0nym> I don't understand how this is soo difficult to do. I'm trying to hook a specific function in a kernel module and modify its return value.

18:37 <p53ud0nym> Does this soun dpossible?

18:40 <fche> p53ud0nym, probe module("..").function("...").return { $return = 65 }

18:40 <fche> if you're seeing problems, please provide a fuller script etc.

18:40 <fche> [man error::reporting]

18:49 <p53ud0nym> fche: http://pastebin.com/4HHw83GG - I cannot place probes at line 1005-1008

18:53 <fche> yeah, the compiler will not guarantee you/us that any particular source line number will be uniquely-enough mapped to an object code address

18:53 <fche> (btw stap has line-range statement probes too: .statement("*@drivers/mod.c:1003-1010")

18:54 <fche> so if the .function.return probe alone is not enough (if say you need to examine some other state beforehands), consider using a .return probe (to override $return), -and- a .statement probe to record the goings-on

18:54 <fche> those probes can communicate via script-level global variables.

18:55 <p53ud0nym> Thanks, i'll try it out.

18:55 <fche> you could also try compiling the module (if it's a custom one) with less optimization

19:00 <p53ud0nym> hmm, now in a module(...).function(...).return probe. The function returns a variable localy defined as ret i.e. `return ret`.

19:00 <p53ud0nym> When i try to modify this in a return probe i gte the following error

19:00 <p53ud0nym> semantic error: write to target variable not permitted in .return probes: identifier '$ret'

19:01 <fche> $return there

19:05 <p53ud0nym> It worked...

19:06 <p53ud0nym> The C code is "return ret;"...

19:06 <p53ud0nym> Thank you!!

19:07 <jistone> $ret tries to access a local by that name; $return uses the actual return value as described by dwarf, in .return probes only -- note in general this might not have any local name at all (could be any expression)

21:04 <irker559> systemtap: flu systemtap.git:refs/heads/master * release-3.0-150-gaa52cbb / NEWS tapset/linux/conversions.stp tapset/linux/netfilter.stp testsuite/systemtap.examples/network/packet_contents.meta testsuite/systemtap.examples/network/packet_contents.stp testsuite/systemtap.examples/network/packet_contents.txt translate.cxx: PR19953: netfilter packet content dumping http://tinyurl.com/ha8e62q