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]
<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>
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>
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?
<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