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
blue_fei1t has joined #systemtap
scox has joined #systemtap
hpt has quit [Ping timeout: 255 seconds]
orivej has quit [Ping timeout: 264 seconds]
blue_feint has quit [Ping timeout: 268 seconds]
hpt has joined #systemtap
sanoj has joined #systemtap
hpt has quit [Ping timeout: 255 seconds]
hpt has joined #systemtap
blue_feint has joined #systemtap
blue_feint has joined #systemtap
blue_feint has quit [Changing host]
blue_fei1t has quit [Ping timeout: 250 seconds]
hpt has quit [Ping timeout: 246 seconds]
hpt has joined #systemtap
sanoj has quit [Quit: Leaving]
sanoj has joined #systemtap
blue_feint has quit [Quit: leaving]
dmalcolm has quit [Ping timeout: 248 seconds]
slowfranklin has joined #systemtap
pwithnall[m] has quit [*.net *.split]
dmalcolm has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
slowfranklin has quit [Client Quit]
sanoj has quit [Ping timeout: 260 seconds]
pwithnall[m] has joined #systemtap
pwithnall[m] has quit [Ping timeout: 240 seconds]
bendlas has quit [Ping timeout: 269 seconds]
sanoj has joined #systemtap
pwithnall[m] has joined #systemtap
scox has quit [Ping timeout: 250 seconds]
bendlas has joined #systemtap
wcohen has quit [Ping timeout: 255 seconds]
hpt has quit [Quit: Lost terminal]
sanoj has quit [Quit: Leaving]
gromero has joined #systemtap
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
wcohen has joined #systemtap
scox has joined #systemtap
orivej has joined #systemtap
hpt has joined #systemtap
jmoyer has joined #systemtap
tromey has joined #systemtap
brolley has joined #systemtap
<jmoyer> are people aware that system call probes are broken in 4.17?
<fche> hey Jeff, in what way?
<jmoyer> fche: let me get you the error
<jmoyer> fche: this will take a few minutes, I have to rebuild and reboot my kernel
<fche> np, starting up a rawhide vm here to play
<jmoyer> fche: but basically, the syscall stubs were renamed, I believe
<fche> IS THERE NOTHING HOLY?
<jmoyer> heh
<jmoyer> yes, it's frustrating
<jmoyer> semantic error: while resolving probe point: identifier 'syscall' at /root/fio/io_submit.stp:23:7
<jmoyer> source: probe syscall.io_submit {
<jmoyer> semantic error: no match
<jmoyer> ^
<jmoyer> fche: ^^^
<fche> ok, that's pretty generic. could you try with stap --vp 02 ?
<jmoyer> sure
<fche> hm okay, will try to reproduce here first of all with rawhide kernel
<jmoyer> fche: ok
mbenitez has quit [Quit: To office]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #systemtap
<fche> jmoyer, hey
<fche> fwiw stap on rawhide does seem to work
<fche> (except for a arch_prctl syscall the tapset can't find)
<jmoyer> fche: what kernel version?
<fche> Linux vm-rawhide-64 4.17.0-0.rc3.git4.1.fc29.x86_64 #1 SMP Fri May 4 19:41:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
<jmoyer> fche: interesting. I wonder if it's some config difference
<jmoyer> or toolchain
<jmoyer> err, not toolchian
<fche> well, what if the io_submit call (only) got messed with?
<jmoyer> seems unlikely, since the syscall wrappers are for every system call
<jmoyer> fche: what script were you using for testing?
<fche> was just doing some random smoketesty ones .... probe syscall.* {}
<fche> but I'm seeing some problems here too now --- important: YOU ARE NOT HALLUCINATING
<fche> :'-)
hpt has quit [Quit: Lost terminal]
<jmoyer> heh
<jmoyer> fche: on a different topic, I've got some updates to io_submit.stp. Previously I've emailed patches to the list, but have had varying success. Do bugs need to be filed for patches?
<fche> are these the newfangled __ia32_sys_FOOBAR __se_sys_FOOBAR __x64_sys_FOOBAR function?
<fche> nah, we're not too formal with these things
<jmoyer> fche: I would have to dig through the macros
<jmoyer> give me a minute
<fche> if there is a bz, it'd get automatically listed in the next release notes
<jmoyer> ok, thanks
<jmoyer> heh
<fche> so if I read that very fine article properly, we should redirect our very fine tapset toward __do_sys_FOOBAR
mbenitez has joined #systemtap
<jmoyer> fche: note that x86 is the only architecture to implement these wrappers right now
<jmoyer> fche: other architectures could choose whatever name they like. hopefully they would follow convention.
<fche> the stap tapset can adapt to different architectures/versions OK
<jmoyer> fche: hmm, I don't think you want the __do variant:
<jmoyer> static inline long __do_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))
<jmoyer> it's inline, and apparently systemtap can't perform return probes on inlines?
<fche> stap can if the compiler is good 'nuff
<fche> and rawhide seems to be:
<fche> [11:47:03] % stap -L 'kernel.function("__do_sys_accept")'
<fche> kernel.function("__do_sys_accept@net/socket.c:1629") $upeer_addrlen:int* $upeer_sockaddr:struct sockaddr* $fd:int
<fche> gcc-8.1.1-1.fc29.x86_64
<jmoyer> try:
<jmoyer> well, I don't know your syntax... but that's not a return probe, right?
<fche> ah true, you said return probes
<fche> sorry thought you said $context vars
<jmoyer> np
<fche> yeah, return probes not possible on inlined functions because .. they're inlined and don't return exactly ... at least gcc doesn't tell us where/how
<jmoyer> fche: using the x64 variant appears to work
<jmoyer> the se variant appears to also be inlined in my kernel for some reason
<fche> stap -L 'kernel.function("__*_accept").*'
<fche> the __x64* variants take the pt_regs though
<jmoyer> is that a problem?
<jmoyer> I mean, it's not ideal, for sure.
<fche> we'd have to change the way the $context variables are extracted, not just pick a different function name.
<fche> so a ton more work
<jmoyer> ok
<jmoyer> I'll take your word for it. :)
<fche> direct your gaze at ...../share/systemtap/tapset/linux/sysc_*
<jmoyer> the __do_sys_X functions aren't explicitly inlined
<jmoyer> I wonder if upstream would be amenable to decorating that with noinline
<jmoyer> uh, brain fart
<fche> then this rewiring would incur a net new level of nesting at run time
<jmoyer> yes it is inlined explicitly
<jmoyer> :)
<jmoyer> fche: so... what do you think is the best way forward?
<fche> not sure yet
<fche> getting a census of what other tracing widgets prefer to use --- bite the bullet and go for the sys-enter/exit tracepoints
<fche> (slowing down the whole system instead of just one syscall)
<jmoyer> ok
<jmoyer> thanks for looking into it
<fche> jmoyer, so methinks this merits a big fat bugzilla entry to track the work
<fche> I can't think of a shortcut solution ... consuming the pt_regs is likely what we will need to do :(
<jmoyer> ugh
<jmoyer> that's unfortunate
<jmoyer> I did have a look at all of the sysc_* files... that's a lot
<jmoyer> rather, there are a lot of them
<fche> yup, painstakingly built, morsel by morsel
mbenitez has quit [Read error: Connection reset by peer]
mbenitez_ has joined #systemtap
wcohen has quit [Ping timeout: 240 seconds]
scox has quit [Ping timeout: 256 seconds]
wcohen has joined #systemtap
wcohen has quit [Ping timeout: 240 seconds]
wcohen has joined #systemtap
brolley has quit [Ping timeout: 256 seconds]
scox has joined #systemtap
brolley has joined #systemtap
scox has quit [Ping timeout: 276 seconds]
scox has joined #systemtap
jmoyer has left #systemtap ["."]
wcohen has quit [Ping timeout: 240 seconds]
mjw has joined #systemtap
mbenitez_ has quit [Quit: Leaving]
gromero has quit [Ping timeout: 240 seconds]
scox has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 26.1)]
wcohen has joined #systemtap
brolley has left #systemtap [#systemtap]
zodbot has quit [Disconnected by services]
dmalcolm has quit [Ping timeout: 240 seconds]
dmalcolm has joined #systemtap
zodbot has joined #systemtap