fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
scox has joined #systemtap
hpt has joined #systemtap
sean__ has quit [Ping timeout: 250 seconds]
philip_ has quit [Quit: philip_]
ananth has joined #systemtap
srikar_away is now known as srikar
CME has quit [Ping timeout: 264 seconds]
ravi_ has joined #systemtap
hpt has quit [Ping timeout: 250 seconds]
hkshaw has joined #systemtap
hpt has joined #systemtap
hchiramm has quit [Ping timeout: 258 seconds]
irker866 has quit [Quit: transmission timeout]
hchiramm has joined #systemtap
hchiramm has quit [Ping timeout: 258 seconds]
hkshaw has quit [Ping timeout: 256 seconds]
zodbot has quit [Remote host closed the connection]
fche has quit [Ping timeout: 250 seconds]
fche has joined #systemtap
zodbot has joined #systemtap
hkshaw has joined #systemtap
sean__ has joined #systemtap
hchiramm has joined #systemtap
sean__ has quit [Ping timeout: 252 seconds]
hpt has quit [Ping timeout: 240 seconds]
hpt has joined #systemtap
ego_ has joined #systemtap
nkambo has joined #systemtap
hpt has quit [Ping timeout: 265 seconds]
hpt_ has joined #systemtap
philip_ has joined #systemtap
nkambo1 has joined #systemtap
nkambo has quit [Ping timeout: 240 seconds]
gila has joined #systemtap
gila has quit [Quit: Textual IRC Client: www.textualapp.com]
philip_ has quit [Remote host closed the connection]
gila has joined #systemtap
philip_ has joined #systemtap
hkshaw has quit [Ping timeout: 250 seconds]
hkshaw has joined #systemtap
philip__ has joined #systemtap
philip__ is now known as pwithnall
sean__ has joined #systemtap
ego_ has quit [Ping timeout: 265 seconds]
hpt_ has quit [Quit: Lost terminal]
philip_ has quit [Quit: philip_]
ego_ has joined #systemtap
sean__ has quit [Ping timeout: 248 seconds]
hkshaw has quit [Ping timeout: 265 seconds]
scox has quit [Ping timeout: 250 seconds]
ananth has quit [Quit: Leaving]
gila has quit [Remote host closed the connection]
gila has joined #systemtap
ravi_ has quit [Quit: Leaving]
ego_ has quit [Ping timeout: 240 seconds]
pwithnall has left #systemtap [#systemtap]
pwithnall has joined #systemtap
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
gila has quit [Quit: Textual IRC Client: www.textualapp.com]
gila has joined #systemtap
sean__ has joined #systemtap
pwithnall has left #systemtap [#systemtap]
pwithnall has joined #systemtap
jemarch has joined #systemtap
<jemarch> yo
mbenitez has joined #systemtap
mjw has joined #systemtap
<jemarch> mjw: I am rebasing the sparc port to master. Want to submit it this week.
<mjw> nice!
<jemarch> well, commit 906d6fe632cc90422928cf681c097d72d9d6b8f1 (cleanup of runtime/linux/loc2c-runtime.h) allowed me to remove a lot of sparc-specific stuff from there
<jemarch> but
<jemarch> there is a little issue
<mjw> jemarch, drsmith should be around later today. He did the loc2c cleanup.
<mjw> And maybe rth will also join, he is poking around that area too.
wcohen has quit [Ping timeout: 252 seconds]
<jemarch> now there are no per-architecture k_{fetch,store}_register in linux/loc2c-runtime.h. They just use pt_regs_{fetch,store}_register that are defined per-arch in linux/../loc2c-runtime.h
<mjw> I believe he claimed some user/kernel DS stuff only mattered for s390x, but I believe sparc64 might join the fun.
<jemarch> However, in sparc most registers are available in the pt_regs structure, but some have to be fetched from the stack.
<mjw> I think rth is going to love you!
sean__ has quit [Ping timeout: 268 seconds]
<mjw> fche, might know better if this overlaps with drsmith's and/or rth's work. But seem to remember them muttering about user/kernel register access cleanups.
<fche> yo
<mjw> and there he is! :)
scox has joined #systemtap
<fche> jemarch, I don't think there is a problem if your pt_regs_{}_register functions do stack accesses
<jemarch> hm
<fche> as long as they use atomic (non-faulting etc.) modes
<jemarch> I had this in my port: https://paste.debian.net/902170/
<jemarch> well, it sounds weird for pt_regs_{fetch,store}_register macros to access memory, but I am fine with it :)
<fche> if they must, they must
<jemarch> ok, so no arch-specific code in linux/loc2c-runtime.h
<fche> well loc2c-runtime.h already has some arch-specific stuff
<jemarch> it had much more before. I really wish that revamp happened _before_ I wrote the sparc port :)
<fche> so it goes :-)
<fche> anyway imaybe you could hang off of the pt_regs_fetch_register function/macro
<fche> and define the sparc specifics in runtime/loc2c-runtime.h (vs. runtime/linux/loc2c-runtime.h)
<jemarch> the pt_regs_*_register macros are defined in runtime/loc2c-runtime.h
<fche> yup
drsmith has joined #systemtap
<jemarch> hmm
drsmith is now known as drsmith_away
<jemarch> however, I need to use flusw_all() in kernel accesses and flush_user() in user accesses. But in pt_regs_{fetch,store}_register I don't have visibility whether I get kernel regs or user regs...
ego_ has joined #systemtap
<fche> ah yeah ... suppose you could reverse-engineer that from matching the pt_regs* being == c->kregs or c->uregs
drsmith_away is now known as drsmith
sean__ has joined #systemtap
<jemarch> ugh
<fche> yeah
<fche> re. flush_* ... are those atomic operations in the kernel context? I bet not
<jemarch> no
<jemarch> wouldn't it be better to keep the pt_regs_* free of such side effects?
<fche> sure, I'm just trying to find out what's possible (from the atomic kernel context)
<fche> how much impact would the drastic policy of making registers 16..32 -unavailable- be?
<jemarch> catastrophic
<jemarch> :)
<jemarch> the functions return address is stored in %i7, for example
<fche> wonder if we can assume that the register windows are already flushed by this point
<jemarch> hmm
<jemarch> certainly not in the kernel accesses
<jemarch> the user ones, probably yes
<fche> certainly not for kernel --- can you explain that? it probably depends on the probe infrastructure; kprobes vs tracepoints vs other stuff (which may not have pt_regs usable at all)
<jemarch> ah wait
<jemarch> right, it comes from a kprobe
<jemarch> hmm, you are probably right
<jemarch> let me look at it..
<jemarch> I can assume that whoever is calling {u,k}_{fetch,store}_* is providing an usable pt_regs right?
<fche> yes
<jemarch> phew :)
<jemarch> ok
<jemarch> I think I will just remove the flushing stuff
<jemarch> hmm, the deref_* macros are defined in runtime/linux/loc2c-runtime.h after runtime/loc2c-runtime.h is included.
<jemarch> Sorry for the naive questions btw. I am not that familiar with systemtap's code organization :)
<jemarch> So I better use the kernel sparc non-faulting memory access functions in pt_regs_*
<fche> worth a shot.
<fche> we're not super rigid with this sort of stuff. if an architecture needs weird exceptions, we can let that happen.
<fche> it just needs to be done tastefully
<jemarch> :)
<mjw> yummy, tasteful patches
<jemarch> wait to see my port, you won't want to taste it :D
<jemarch> I noticed during the rebase that mips support got added in the meanwhile. Very nice
wcohen has joined #systemtap
hkshaw has joined #systemtap
srikar is now known as srikar_away
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
brolley has joined #systemtap
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
ego_ has quit [Ping timeout: 246 seconds]
pwithnall has quit [Quit: pwithnall]
pwithnall has joined #systemtap
tromey has joined #systemtap
irker423 has joined #systemtap
<irker423> systemtap: dsmith systemtap.git:refs/heads/master * release-3.0-315-g1f19391 / runtime/linux/autoconf-relay_buf-per_cpu_ptr.c: Improve relayfs autoconf test for F24. http://tinyurl.com/hfvdq2v
srikar_away has quit [Ping timeout: 245 seconds]
srikar_away has joined #systemtap
<irker423> systemtap: dsmith systemtap.git:refs/heads/dsmith/python * release-3.0-360-ge01cd0b / : Add tests for python 2 and python 3 probes. http://tinyurl.com/gt2fdbh
<jistone> drsmith, thanks, it's behaving on F25 now
<drsmith> jistone: great, sorry for the bother
<fche> thanks guys
<jistone> we'll need to plan soonish for 4.9 to land on fedora
<jistone> at least backport those various fixes
<jistone> but stap 3.0 is getting long in the tooth
<drsmith> on that subject, fche: is there any reason for me not to merge my python code to master?
<jistone> and f25 has a git snapshot from July
<fche> drsmith, your call dude
<fche> if it works well enough for you, please write up some docs for NEWS and an email announcement, the usual sort of pre-release publicity for neat new capability
<fche> sample code etc.
<fche> I have SHIP IT on a hotkey btw.
<fche> but jistone, yeah, maybe this is good enough a feature set for a release
<jistone> possibly bad timing though, with folks about to depart for holidays
<fche> yeah, I don't mean now now, but not holding up the release for e.g. rth's work
<fche> so like early january
<jistone> +1
<jistone> 🎉
<fche> depending on how you squint at that, it could look like all kinds of things
<jistone> ¯\_(ツ)_/¯
<p53ud0nym> Hi, I cannot get stap defines to work. Here is a simple test stap script and its output: http://termbin.com/03wt
<fche> hi
<fche> use @MODULE_NAME
<p53ud0nym> I'm trying to use a define to set a string literal for the name of a kernel module
<p53ud0nym> :D
<p53ud0nym> ty
<fche> see [man stap PREPROCESSOR MACROS]
hchiramm has quit [Ping timeout: 240 seconds]
mbenitez has quit [Quit: To office]
<p53ud0nym> Am I right in assuming SystemTap is only supported on Linux up to version 4.6? What sort of issues would you expect on the latest kernel version?
<fche> p53ud0nym, git systemtap tracks git kernels
<p53ud0nym> fche: thanks.
<fche> the last release of stap - 3.0 - is now quite long in the tooth
<fche> but even that was post 4.6 IIRC
<fche> the next release should do 4.9 final just fine
<fche> the fedora version of systemtap 3.0 includes backported portability fixes so it works fine on 4.8.10 e.g.
<jemarch> When is the next release scheduled for?
<p53ud0nym> fche: I can now compile a stap module for 4.9.0-rc7, thanks.
<fche> right, thanks to fine work from dsmith/jistone & etc
<jistone> jemarch, we don't have a schedule per se, but were just talking this morning about aiming for early january
<jemarch> Any hope for the sparc port to be included if I submit it this week? :)
<fche> if it doesn't regress other platforms, and works well enough for you, I don't see a problem
<jemarch> great! :)
<fche> it'd be neat to have you run a testsuite run with .../configure --enable-dejazilla
<jemarch> ok
<jemarch> what is that?
<fche> (it emails the .sum file to my server here
<fche> so that one can compare the run with others on a little web database thingie)
<jemarch> ah
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
wielaard has joined #systemtap
CME has joined #systemtap
<p53ud0nym> hmmm I'm having trouble finding the probe points in the git version of systemtap. Using `stap -L ...` with systemtap-3.0 and git version reports different probe points.
<fche> can you give some examples?
<drsmith> p53ud0nym: I seem to remember changing the blacklist patterns since 3.0, so if you are seeing more probe points in git systemtap, that is to be expected.
<p53ud0nym> It's the other way round. I have compiled some kernel modules with dwarf symbols for testing purposes. The vanilla stap is finding them, git version isn't.
<p53ud0nym> Did I need to enable any debugging information when compiling stap from source to use dwarf symbols?
<p53ud0nym> I couldn't find any.
<drsmith> p53ud0nym: Assuming you are compiling by hand, a simple "configure; make; make install" should work fine
<drsmith> what version of elfutils do you have installed on your system?
<p53ud0nym> Here is what i'm seeing: http://termbin.com/l837
<p53ud0nym> elfutils 0.166-2.2
<jemarch> damn, pt_regs_{fetch,store}_register(pt_regs, regno) must know if the pt_regs are kernel registers or user registers, there is no way to avoid it. Unless there is some magical function in the kernel that would tell you whetehr a passed pointer points to kernel memory or to user memory?
<fche> the pt_regs structure itself will be in kernel memory regardless
<fche> but remember the gross idea from earlier; compare pt_regs* to c->kregs and c->uregs -- it'll be one of those
<jemarch> yes, but the frame pointer stored in pt_regs points to either user or kernel
<jemarch> yeah, I just hate the idea of the macro using the c global :)
<fche> understood, that is indeed Problematic
<fche> one could widen the function argument list, add a user_p flag or something
<jemarch> yes, but then everyone will hate me and bully me, as I am the new one :'(
<fche> that much is true
<fche> such is the burden we carry - to be bullied and hated for our good work
<jemarch> Tou tell me. GNUdist since the late 90s :D
<jemarch> well... comparing pt_regs to c->kregs and c->uregs is certainly the easiest way... tempting.. :)
<fche> I'll leave it to you and your conscience :)
<fche> p53ud0nym, the non-git version's output looks suspect
<fche> all those multiple-line-numbers for the same-function are probably wrong
* fche thinks this was a bug deliberately fixedd
<fche> (being fixedd is better than merely being fixed.)
<p53ud0nym> Ok, but those multiple line-numbers allow be to place more statement probes. Right? I'll test it.
<p53ud0nym> Perhaps listing function probes was a bad idea. Here is the output for statement probes: http://termbin.com/agcq.
<p53ud0nym> The git version does not allow me to place probes not listed in it's output.
hchiramm has joined #systemtap
wielaard has quit [Quit: Leaving]
<fche> previous version of the code may not have properly separated treatment of .statement vs .function probes
<fche> the new .statement list you transcribe is ... not right though
<fche> the new .function looks ok
<fche> two steps forward, one back, etc.
CME has quit [Ping timeout: 264 seconds]
<irker423> systemtap: jistone systemtap.git:refs/heads/master * release-3.0-316-gba99b10 / elaborate.cxx staptree.cxx staptree.h translate.cxx: Simplify embedded-tags visitors http://tinyurl.com/z4xskfz
CME has joined #systemtap
brolley has left #systemtap [#systemtap]
tromey has quit [Quit: ERC (IRC client for Emacs 25.1.90.1)]
scox has quit [Ping timeout: 265 seconds]
mbenitez has quit [Quit: Leaving]
wcohen has quit [Ping timeout: 268 seconds]
drsmith is now known as drsmith_away
gila has quit [Read error: Connection reset by peer]
gila has joined #systemtap
pwithnall has quit [Quit: pwithnall]