fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
khaled has quit [Quit: Konversation terminated!]
gromero has quit [Ping timeout: 272 seconds]
gromero has joined #systemtap
derek0883 has quit [Ping timeout: 260 seconds]
sscox has quit [Ping timeout: 256 seconds]
amerey has quit [Ping timeout: 244 seconds]
amerey has joined #systemtap
derek0883 has joined #systemtap
hpt has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
sscox has joined #systemtap
derek0883 has quit [Ping timeout: 244 seconds]
derek0883 has joined #systemtap
orivej has joined #systemtap
hpt has quit [Quit: Lost terminal]
khaled has joined #systemtap
hpt has joined #systemtap
hpt has quit [Quit: Lost terminal]
hpt has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
hpt has quit [Ping timeout: 258 seconds]
derek0883 has quit [Ping timeout: 244 seconds]
mjw has joined #systemtap
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
derek0883 has joined #systemtap
orivej has joined #systemtap
derek0883 has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 260 seconds]
mjw has quit [Read error: Connection reset by peer]
orivej has joined #systemtap
mjw has joined #systemtap
wcohen has quit [Remote host closed the connection]
wcohen has joined #systemtap
tromey has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
orivej has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
khaled has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Ping timeout: 272 seconds]
tromey has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
mjw has quit [Quit: Leaving]
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
derek0883 has quit [Remote host closed the connection]
derek0883 has joined #systemtap
gromero has quit [Ping timeout: 272 seconds]
<agentzh>
fche: seems like statement(HEX).absolute actually means skipping instruction/statement boundary checks as per dwarf? instead of meaning absolute virtual memory addresses after ASLR or KASLR relocating?
<fche>
well how about both ?
<agentzh>
hmm, kernel.statement(HEX).absolute at least uses relative kernel addresses.
<agentzh>
like those from /proc/kallsyms.
<fche>
those are absolute
<agentzh>
and 'man stapprobes' actually states that.
<agentzh>
oh really? but i checked that /proc/kallsyms's offsets do match System.map's entries.
<agentzh>
so both of them are absolute?
<agentzh>
they seem constant.
<agentzh>
not subject to KASLR.
<fche>
unless obfuscated by the kernel, kallsyms is 'absolute' in the sense that they are actual runtime addresses
<fche>
kallsyms better be correct -after- kaslr (if any)
<agentzh>
so in my case, KASLR is not actually enabled?
<agentzh>
in which case the addresses do match?
* fche
has no way of knowing :)
<agentzh>
okay, checked /proc/cmdline, and it says nokaslr
<agentzh>
so i gather it is not enabled at all.
<agentzh>
is there a way to skip instruction/stmt boundary checks for kernel.statement(HEX)?
<agentzh>
because this requires kernel debuginfo.
<fche>
instruction boundaries are checked by kprobes infrastructure
<fche>
dwarf statement boundaries are checked by stap, but not for the .absolute variant
<agentzh>
yeah, but as you mentioned, .absolute is the absolute address, which cannot be known before a kaslr kernel is booted. is that correct?
<agentzh>
so i think we do need the non-absolute case.
<agentzh>
oh btw, the kernel.statement.absolute case still requires kernel debuginfo, i think it's a bug?
<fche>
ok so that'd be vmlinux time addressess
<fche>
hm don't see why it should require debuginfo
<agentzh>
yep, using addresses in System.map.
<agentzh>
i think that's the relative addresses accepted by the non-absolute probes, right?
<agentzh>
fche: at least according to a simplest stap script, the absolute one still complains about missing kernel debuginfo. we have a patch for it. willing to have a look?
<agentzh>
but that's a separate matter.
<agentzh>
seems like we still need a feature to disable stmt/insn boundary checks and kernel debuginfo requirements on the non-absolute case as well.
gromero has joined #systemtap
<fche>
can have a look
<fche>
system.map ... wouldn't call them 'relative'
<fche>
would just call them, dunno, linked addresses?
<fche>
if kaslr happens, especially if broken down by functions, then they're not relative to anything in particular
<fche>
they are just scrambled all over the place ;)
<agentzh>
fche: then how can we find the addresses used for probe kernel.statement(HEX) ?
<fche>
well stap/runtime will take care of computing the runtime addresses somehow(tm)
<fche>
the hex addresses here would be the link-time addresses from the vmlinux / symbol maps
<agentzh>
okay, so we should not read System.map for it?
<agentzh>
i though System.map was the "symbol maps" you just mentioned ;)
<agentzh>
*thought
<fche>
well that has addresses in the same coordinate system as the vmlinux image
<fche>
re. debuginfo-less .absolute .... ah, I remember touching this code not too long ago, so this is a partial revert of that work, right?
<agentzh>
i'm not sure.
<agentzh>
i haven't looked at your recent changes.
<fche>
not too recent
<agentzh>
i just avoided using hard-coded debuginfo_needed = true arg value in this patch.
<agentzh>
it just doesn't make sense to me ;)
<agentzh>
it's using the default arg value, true, for that arg.
<fche>
I wonder if this kernel.statement(HEX).absolute should be grouped with the kprobe.* probe family instead, which keeps it far away from dwarf processing generally
* agentzh
tries to remove the nokaslr boot option from his system.
<agentzh>
that sounds like a big change...
<agentzh>
maybe we can get this patch in first?
<agentzh>
if it has no issues?
<fche>
sure.
<fche>
(looked briefly through the logs, and don't have a reason not to go with this for now.)