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
philip_ has quit [Remote host closed the connection]
gila_ has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
<bendlas>
fche: problem persists with 4.9.4, could you confirm, that it works with the 4.9 series of kernels for you? the vanilla one?
Humble has quit [Ping timeout: 245 seconds]
gila has joined #systemtap
philip_ has joined #systemtap
Humble has joined #systemtap
scox has quit [Ping timeout: 240 seconds]
ravi has quit [Ping timeout: 245 seconds]
philip_ has quit [Ping timeout: 255 seconds]
ananth has quit [Quit: Leaving]
hkshaw has quit [Ping timeout: 240 seconds]
hkshaw has joined #systemtap
Humble has quit [Read error: Connection reset by peer]
Humble has joined #systemtap
hkshaw has quit [Ping timeout: 240 seconds]
Humble has quit [Ping timeout: 240 seconds]
Humble has joined #systemtap
hkshaw has joined #systemtap
hkshaw1 has joined #systemtap
<fche>
bendlas, I haven't seen a kernel where this didn't work, right up to 4.10-rc
hkshaw has quit [Ping timeout: 260 seconds]
<bendlas>
fche: do you run the fedora patchset? I can try to build a kernel with it to see if it makes any difference. Also I'll try a kernel without the (few) patches, we run in NixOS.
<fche>
yes, usually, but we have users in many other distros too
wcohen has quit [Ping timeout: 240 seconds]
nkambo has quit [Ping timeout: 255 seconds]
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
nkambo has joined #systemtap
hpt has joined #systemtap
hpt has quit [Ping timeout: 240 seconds]
hpt has joined #systemtap
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
scox has joined #systemtap
hpt has quit [Quit: Lost terminal]
wcohen has joined #systemtap
groleo has joined #systemtap
drsmith has joined #systemtap
tromey has joined #systemtap
<bendlas>
fche: I think I found the issue: I'm trying to build with an external build directory: `mkdir build; make O=build defconfig; make O=build` and then `stap -r build ...`
<bendlas>
this used to work until recently, so I'd assume there is some breakage in the kernel makefiles, that only appears in this uncommon case.
<fche>
curious,
<fche>
not surprised that a sort of fake build tree doesn't work
<fche>
but am surprised about this symptom showing the problem
brolley has joined #systemtap
<bendlas>
well, our distro package delivers this (+ Modules.symvers + vmlinux) as its module-dev package and we build all sorts of external packages with it. Maybe Linux is interested in fixing this case ...
<bendlas>
Of course, I can recreate a build dir for systemtap. Copying `.config` and `Module.symvers` to a source directory and running `make modules_prepare` should do it, right?
jemarch has joined #systemtap
<jemarch>
yo
<jemarch>
is it even possible to have k_regs and u_regs set simultaneously in a probe context? I guess that depends on the probe type, but as far as I can see at the moment all the probe types set either k_regs or u_regs.
<jemarch>
... but not both
gila has joined #systemtap
mjw has quit [Quit: Leaving]
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
gila has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 25.1.91.1)]
jhg_ has joined #systemtap
gila has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
tromey has joined #systemtap
pwithnall has quit [Ping timeout: 248 seconds]
hkshaw1 has quit [Ping timeout: 245 seconds]
<fche>
hi jemarch , yeah, those reflect the register dumps that the kernel gives us when it enters the systemtap callbacks
<fche>
and yeah it is one or the other
<fche>
now for backtracing (from kernel to userspace), stap will partly unwind kernel stacks in order to populate a partial userspace register set, with which it can do a userspace unwind
<fche>
but that's not exposed as a general purpose facility
<jemarch>
ok
<jemarch>
still polishing the port... got rid of the kernel/user distinction problem in sparc's ptrace by using the user_mode macro defined in ptrace.h, and the 32/64 bits distinction problem by looking at the least significative bit of the user stack pointer (which is 1 for 64-bit user processes, 0 for 32-bit user processes)
<jemarch>
however something broke with the recent loc2c-runtime upstream refactor and now the port panics the kernel :/
<jemarch>
probably some of the generic kernel mechanisms that loc2-runtime now uses is malfunctioning on sparc, or (most likely) have some slightly different semantics than in the other ports
<fche>
whoops
<fche>
hm which loc2c-runtime upstream refactor?
<fche>
rth has been working on one but that's not done / merged yet
<jemarch>
back when I wrote the port there was quite a lot of arch-specific stuff in runtime/linux/loc2c-runtime.h
<jemarch>
like arch-specific deref macros
<jemarch>
"recently" upstream changed to use the generic uaccess.h stuff instead
<jemarch>
get_user and such
<fche>
ah linux lkml upstream
<fche>
not stap upstream
mbenitez has quit [Ping timeout: 240 seconds]
mbenitez has joined #systemtap
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
irker957 has joined #systemtap
<irker957>
systemtap: dsmith systemtap.git:refs/heads/rth/bpf * release-3.0-408-gca67717 / systemtap.spec: Move and update comment in systemtap.spec. http://tinyurl.com/j3xv2ck