fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
pwithnall_____ has quit [Ping timeout: 240 seconds]
_whitelogger has joined #systemtap
scox has joined #systemtap
gromero has quit [Ping timeout: 255 seconds]
hpt has joined #systemtap
RustJason has joined #systemtap
<introom>
how is ebpf support in systemtap? and is there any performance difference between current ebpf (bcc) and systemtap ?
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
RustJason has joined #systemtap
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
RustJason has joined #systemtap
sanoj has joined #systemtap
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pwithnall_ has joined #systemtap
pwithnall_ has quit [Quit: pwithnall_]
pwithnall_____ has joined #systemtap
RustJason has joined #systemtap
slowfranklin has joined #systemtap
nkambo_ has joined #systemtap
nkambo has quit [Ping timeout: 255 seconds]
<slowfranklin>
Hi folks!
<slowfranklin>
Anyone around that might be able to tell why something like this would fail:
<slowfranklin>
If I use the path instead of the pid it works
<slowfranklin>
Systemtap translator/driver (version 3.1/0.169, rpm 3.1-5.fc25) this is
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #systemtap
mjw has joined #systemtap
hpt has quit [Quit: Lost terminal]
RustJason has joined #systemtap
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sanoj has quit [Quit: Leaving]
pwithnall_ has joined #systemtap
pwithnall_ has quit [Quit: pwithnall_]
RustJason has joined #systemtap
gromero has joined #systemtap
wcohen has quit [Ping timeout: 240 seconds]
drsmith_away is now known as drsmith
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
gromero has quit [Ping timeout: 240 seconds]
<fche>
hm maybe the .library("*") part of the logic doesn't know how to handle pid#'s
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gromero has joined #systemtap
wcohen has joined #systemtap
<slowfranklin>
hm
<slowfranklin>
I'm using the processname and just pass -x pid for now
<slowfranklin>
thanks
<fche>
righto
hpt has joined #systemtap
RustJason has joined #systemtap
brolley has joined #systemtap
gila_ has quit [Ping timeout: 246 seconds]
gila has joined #systemtap
drsmith is now known as drsmith_away
drsmith_away is now known as drsmith
plhu has joined #systemtap
RustJason has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 240 seconds]
drsmith is now known as drsmith_away
drsmith_away is now known as drsmith
<plhu>
Hello, I try to understand the arguments of setsockopt syscall but I have no idea how to understand its argument values. Is there any place e.g. in kernel docs/code to look at?
<fche>
setsockopt is kind of like ioctl - it is not one call but a family of functions hidden in one
<fche>
Have you seen [man setsockopt] and want to look at the implementation in the kernel?
<plhu>
fche: I read the setsockopt man page and found a reference to socket(7) and I remember somehow how this works, but I have no idea where to find the mapping of socket option names SO_* to the binary flags.
<fche>
/usr/include/asm-generic/socket.h from glibc ?
<plhu>
fche: thanks. Did you already know this or is there any doc that have not come to my mind?
hpt has quit [Ping timeout: 260 seconds]
<plhu>
I mean, looking for socket.* or in glibc ogre grepping its header files to SO_ should come to my mind but if there would be some other way, I would like to know for the future.
<slowfranklin>
Damn. I'm not really familiar with the magic of stripping debug symbols from binaries and how they're put into seperate RPMs and how the tools put it all together again
<fche>
do you have a rpm version/release list, to ensure there's no mismatch there?
<slowfranklin>
On the Fedora system I'm just directly working with binaries from from a build of a git checkout
<slowfranklin>
On the RHEL system it's all from rpmbuild with seperate debug sym RPM
<fche>
that should all Just Work (tm); stap (elfutils) knows about such conventions
<slowfranklin>
Yeah
<slowfranklin>
Afair it works for eg gdb, but lemme check
<slowfranklin>
ahhhhhhh, looks like someone messed up the packages...
<slowfranklin>
This is from attaching with gdb to a process:
<slowfranklin>
Reading symbols from /usr/lpp/mmfs/lib64/samba/vfs/shadow_copy2.so...
<slowfranklin>
warning: the debug information found in "/usr/lib/debug//usr/lpp/mmfs/lib64/samba/vfs/shadow_copy2.so.debug" does not match "/usr/lpp/mmfs/lib64/samba/vfs/shadow_copy2.so" (CRC mismatch).
<slowfranklin>
warning: the debug information found in "/usr/lib/debug/usr/lpp/mmfs/lib64/samba/vfs/shadow_copy2.so.debug" does not match "/usr/lpp/mmfs/lib64/samba/vfs/shadow_copy2.so" (CRC mismatch).
<slowfranklin>
Reading symbols from /usr/lpp/mmfs/lib64/samba/vfs/shadow_copy2.so...(no debugging symbols found)...done.
<slowfranklin>
(no debugging symbols found)...done.
* fche
cries quietly in the rain
* slowfranklin
head hits table
<slowfranklin>
Thanks a *lot* for pointing me in the right direction!
<fche>
no problemo
<fche>
we really should get the tool to explain these situations better
<fche>
(and at the same time not drown people in info, like that --vp 02 does)
<slowfranklin>
I guess a big warning that debug symbols can't be found *whenever* a user uses those probes might make sense?
<fche>
well, except that stap can do -some- stuff without, like place all those .function probes
<fche>
it's the $vars that triggered the dwarf need
<slowfranklin>
yup
<slowfranklin>
Fwiw, I'm currently adding probes to Samba as well as write several script for instrumentation
<fche>
excellent
<slowfranklin>
I really really like this stuff!
<mjw>
fche, do you have an idea of what/when stap should say to make this easier for users?
<mjw>
slowfranklin, or you. At what point would you have (with hindsight) expected stap to say something that would have saved you some time (and what would that have been).
<slowfranklin>
mjw: hi
<slowfranklin>
From reading man stapprobes I was under the impression that process().function() probes require dwarf debug symbols
<slowfranklin>
That doesn't seem to be the case
<mjw>
So when stap said:
<mjw>
semantic error: unresolved target-symbol expression: identifier '$return' at winbindd.stp:335:44
<slowfranklin>
So an additional error at the point where accessing $return failed would have been helpful
<mjw>
It should have also have said something like:
<mjw>
at address xxx in module foobar (no debuginfo)
<slowfranklin>
yes
<fche>
slowfranklin, see SYMBOL-TABLE mention of process.function also
<mjw>
Lets see, the other probe worked because it could figure out the address for the function "_wbint_PingDc" in winbindd without debuginfo?
<fche>
yes.
<slowfranklin>
yes
<mjw>
OK, that should be doable.
<mjw>
except I don't have time right now... sigh.
<fche>
:)
<slowfranklin>
:)
<slowfranklin>
Nevertheless, thanks for your time! ;) And for your help!
<fche>
slowfranklin, in the mean time, any idea about the nature of the debuginfo mismatch/missingness?
<slowfranklin>
Some sort of packaging madness, someone must have messed up the cluster
<fche>
do you guys have wet noodle executions over there?