fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<toothe>
alright, I'm now running Cinammon - looks great.
<toothe>
like I said, I am not too particular on which distro I run. I prefer to use LInux, not worry about distro hopping.
<fche>
welcome aboard
<toothe>
do you work for Redhat?
<fche>
''work'' is relative :)
<fche>
getting late though
<toothe>
you enjoy it.
<fche>
SOMETIMES
<fche>
but don't tell the boss
<fche>
so on the downside, sometimes fedora kernels do get ahead of fedora systemtap
<fche>
on the upside, the buck stops with our team here, so yeah we get on that and backport whatever needs to be done as soon as we realize the problem
<toothe>
i submitted a bug report before switching distros, heh.
<fche>
I think I saw that.
<fche>
my minions are embedded everywhere
<toothe>
oh? did you really?
<toothe>
that's interesting.
<toothe>
I was reasonably descriptive.
<fche>
yup, looked good
<toothe>
yeah, I ran into this same issue when I was compiling a vmware kernel module - I hacked it a bit until it worked (didn't I say this earlier?)
mmarchini has quit [Ping timeout: 240 seconds]
<fche>
you did
<fche>
maybe it's late for both of us :)
hpt has joined #systemtap
<toothe>
wow, this is nice. There are no file location information in the Fedora stap -l
<toothe>
so, I'll read the man page in bed in a bit -- but I noticed it doesn't list functoin pointers, but the actual function itself.
<toothe>
that's different from dtrace.
<toothe>
hm...I tried several examples, not able to get a function's arguments printed.
<toothe>
I tried $$parms, $$parms$$, and a few other things...odd
<toothe>
hm...apparently there's a pckage I need called debuginfo, but I don't see it anywhere.
hpt has quit [Ping timeout: 252 seconds]
hpt has joined #systemtap
<toothe>
oh, there we go - I didn't have the right debugging packages.
hpt has quit [Ping timeout: 240 seconds]
hpt has joined #systemtap
sanoj has joined #systemtap
_whitelogger has joined #systemtap
gromero has quit [Ping timeout: 255 seconds]
sanoj has quit [Quit: Leaving]
sanoj has joined #systemtap
nkambo has joined #systemtap
sanoj_ has joined #systemtap
sanoj has quit [Ping timeout: 252 seconds]
tonyj has quit [Remote host closed the connection]
irker880 has quit [Quit: transmission timeout]
sanoj_ has quit [Ping timeout: 240 seconds]
sanoj_ has joined #systemtap
mjw has joined #systemtap
hpt has quit [Quit: Lost terminal]
sanoj_ has quit [Quit: Leaving]
sanoj has joined #systemtap
gila has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
<fche>
toothe, yea, for some types of probes/constructs, the debuginfo (~ debian .dbgsym) is required, because you're asking stap to do the same kinds of source-level things as gdb does
<fche>
on solaris, a small but cleverly chosen subset of that debugging info is always embedded in the main binaries
pwithnall_ has joined #systemtap
pwithnall_ has quit [Quit: pwithnall_]
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
mbenitez has quit [Ping timeout: 260 seconds]
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
sanoj has quit [Ping timeout: 248 seconds]
mbenitez has quit [Quit: Leaving]
sanoj has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
gromero has joined #systemtap
wcohen has quit [Ping timeout: 240 seconds]
sanoj has quit [Ping timeout: 240 seconds]
drsmith_away is now known as drsmith
drsmith is now known as drsmith_away
drsmith_away is now known as drsmith
sanoj has joined #systemtap
sanoj has quit [Ping timeout: 246 seconds]
wcohen has joined #systemtap
brolley has joined #systemtap
tromey has joined #systemtap
<toothe>
so, when I installed a newer kernel, the debugging symbols seemed to quit working.
<toothe>
whene I reverted back to 4.11, they appeared again - attempting to install the debug symbols said "They are already installed"
<toothe>
hm..Dont' really feel like hacking that at the moment.
<toothe>
need to figure out how to selectively print out a variable based on who called the probed function.
<fche>
hi
<fche>
try # stap-prep to align the installation stars
<toothe>
howdy!
<toothe>
let me give that a go when I get home! I'm currently remote to the machine.
<fche>
other than that, the stap script proper should be pretty straightforward ... probe kernel.function("foo") { if (caller() =~ "otherfn") println($var$) } /* e.g. */
<toothe>
ahh, caller() -- so, I was reading some documentation last evening. I still haven't figured this stuff out...
<fche>
once this silly debuginfo stuff is figured out, you'll have fun experimenting
<toothe>
well, i just rebooted back to an earlier kernel
irker574 has joined #systemtap
<irker574>
systemtap: dsmith systemtap.git:refs/heads/master * release-3.1-288-g9f2fa5f / runtime/pmap-gen.c: Fix PR22151 by not trying to use a pmap when it is NULL. http://tinyurl.com/y95w7uk8
<toothe>
maybe I should explain what I am trying to do?
<fche>
what module/kernel-image -would- call that module function ?
<fche>
try stap --all-modules .....
<toothe>
In my use-case, it would be called by functions in the module rtl8188ee
<toothe>
there are 3 modules that build off each other rtlwifi -> rtl_pci -> rtl8188ee
<toothe>
rtlwifi is realtek's general functions, rtl_pci is specific to PCI, RTL8188ee is specific to a certain wifi card.
<toothe>
so, rtl8188ee reaches back to rtl_pci
<fche>
ok. so one other thing to understand about stap is that to do backtraces / symbol lookup, it needs to know in advance which modules/object-files you might want to look up within
<fche>
it has no a-priori knowledge about rtlwifi etc.
orivej has joined #systemtap
<irker574>
systemtap: penguin-kernel systemtap.git:refs/heads/master * release-3.1-292-g589859d / runtime/linux/task_finder.c runtime/linux/task_finder2.c: Fix PR22155 by avoiding a kernel panic. http://tinyurl.com/y9sm3ukv
<toothe>
fair, you probably don't need to. hopefully I can convert over the concepts you explain :)
<fche>
so stap --all-modules (and related options) tell stap that you'll be interested in module/kernel interactions that go beyond the probe point you already listed
* toothe
runs.
<toothe>
runs that command
<fche>
duck
<toothe>
I read the manual as well. That didn't seem to change antyhing when running it.