fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
jlebon has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 260 seconds]
naveen_ has joined #systemtap
naveen_ has quit [Quit: WeeChat 2.1]
irker885 has quit [Quit: transmission timeout]
sanoj has joined #systemtap
sanoj has quit [Ping timeout: 264 seconds]
sanoj has joined #systemtap
nkambo has quit [Ping timeout: 240 seconds]
sanoj has quit [Ping timeout: 264 seconds]
sanoj has joined #systemtap
naveen has joined #systemtap
nkambo has joined #systemtap
nkambo has quit [Read error: Connection reset by peer]
nkambo has joined #systemtap
nkambo has quit [Ping timeout: 240 seconds]
sanoj has quit [Ping timeout: 265 seconds]
sanoj has joined #systemtap
scox has quit [Ping timeout: 240 seconds]
lorddoskias has joined #systemtap
<lorddoskias>
does systemtap support the ORC unwinder
<lorddoskias>
or should i be using FP ?
mjw has joined #systemtap
sanoj has quit [Ping timeout: 268 seconds]
naveen has quit [Quit: WeeChat 2.1]
orivej has joined #systemtap
<mjw>
ehe?
<mjw>
Pass 5: run failed. [man error::pass5]
<mjw>
WARNING: /home/mark/build/systemtap-obj/staprun/run-staprun exited with status: 127
<mjw>
/var/tmp/scl7OqDQa: line 8: -P: command not found
<mjw>
ok, ignore that, apparently I configured in srcdir by accident causing weirdness in the generated files.
<mjw>
Or something... how odd. I keep getting that. But that /var/tmp file disappears before I can inspect it...
lorddoskias has left #systemtap [#systemtap]
<mjw>
If only we had a tool to catch processes creating files... :)
mbenitez has joined #systemtap
mbenitez has quit [Changing host]
mbenitez has joined #systemtap
jlebon has joined #systemtap
jlebon has quit [Client Quit]
<mjw>
gah, no idea what this is. It only happens if I do an in-build-tree ./run-stap, if I install it and run stap from the install dir it works fine.
<mjw>
weird
jlebon has joined #systemtap
wcohen has quit [Ping timeout: 256 seconds]
scox has joined #systemtap
wcohen has joined #systemtap
naveen__ has joined #systemtap
gromero has joined #systemtap
irker788 has joined #systemtap
<irker788>
systemtap: mark systemtap.git:refs/heads/master * release-3.2-178-g17ee540 / runtime/unwind.c: Make kernel DWARF unwinder work with ksalr. http://tinyurl.com/y9dhu5px
<mjw>
pfff, that took all day. For a oneliner... embarrassing.
tromey has joined #systemtap
<fche>
ship it
<fche>
why is that specific to the kernel btw?
<fche>
I'd imagine the exact same relocation calculation is appropriate for module/sections too
<fche>
mjw^
<mjw>
fche, because the kernel is "special" :)
<mjw>
It is not really relocatable, but then it is, so it looks somewhat like an executable, but really is a shared object, except that it isn't.
<mjw>
So for all other types we already do the right thing.
<fche>
how do we do the right thing for modules already?
<mjw>
fche, at the end of that same function.
<fche>
ah. too bad we have all these offset-like things we must or must not add differently for each type of target
<mjw>
Now that you say it, maybe we could fall-through. But I am a little afraid to do that now.
<mjw>
I did test the module thingy. So it does work for that as it is now.
<mjw>
fche, yeah, so for modules it is even weirder, because they can have multiple .text sections and the kernel itself acts as "dynamic loader" possibly laying out the sections randomly. For user space we don't need to keep track of sections at all, it is just one module.
<mjw>
normally the linker takes care of all that. placing all hot and cold sections together, etc. determining the layout of the ELF module. But the kernel... it is special :)
brolley has joined #systemtap
naveen__ has quit [Quit: WeeChat 2.1]
naveen has joined #systemtap
gila has joined #systemtap
naveen has quit [Quit: WeeChat 2.1]
<tonyj>
What are the current systemtap "rules" on build-ids? Originally we had common build-ids for vmlinuz, vmlinux and vmlinux.debug. We broke this (vmlinuz was different) and started getting errors from stap like "RROR: Build-id mismatch: "kernel" vs. "vmlinux-3.0.34-0.7-default.debug" byte 0 (0x78 vs 0xa6) address 0xffffffff8144d128 rc 0"
<tonyj>
We've managed to break it again (vmlinux and /sys/kernel/notes no longer match vmlinux/vmlinux.debug) but stap no longer seems to care.
<tonyj>
I notice on Fedora27 that the /boot/vmlinuz and /boot/vmlinuz+debug do not have the same build-id.
mjw has quit [Quit: Leaving]
<jistone>
tonyj, I think vmlinuz+debug is a distinct kernel build, with various CONFIG_DEBUG options set
<jistone>
(afaik stap still verifies build-ids, but I'm not directly involved these days)
<tonyj>
jistone: I know before, if /sys/notes/kernel build-id didn't match vmlinux.debug stap would complain. it seems no longer, it doesn't match for us and it's not complaining, I'll have to look at the code.
CME has quit [Read error: Connection reset by peer]
CME has joined #systemtap
irker788 has quit [Quit: transmission timeout]
CME_ has joined #systemtap
CME has quit [Read error: Connection reset by peer]
CME_ is now known as CME
mjw has joined #systemtap
CME has quit [Read error: Connection reset by peer]
CME has joined #systemtap
tromey has quit [Quit: ERC (IRC client for Emacs 26.1)]
amerey has quit [Remote host closed the connection]
mbenitez has quit [Quit: Leaving]
scox has quit [Ping timeout: 256 seconds]
mjw has quit [Quit: Leaving]
brolley has left #systemtap [#systemtap]
<fche>
tonyj, stap -DDEBUG_SYMBOLS should get a little deeper into what it's trying to do
<fche>
but the buildids in question aren't fetched from /sys/notes per se but rather from dereferencing kernel-side addresses computed at -p3 time
<fche>
but yeah it should still check
<fche>
please test git stap, some kaslr-related patches just went in, and might be relevant
wcohen has quit [Remote host closed the connection]