fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
amerey has quit [Quit: Leaving]
<agentzh> and tested on my side.
<fche> lgtm
<agentzh> cool, thanks
irker620 has joined #systemtap
<irker620> systemtap: yichun systemtap.git:refs/heads/master * release-4.2-22-gde25378 / NEWS tapset/linux/proc_mem.stp: Tapset: proc_mem_rss() now includes resident shared mem pages. http://tinyurl.com/vayu7dz
khaled has quit [Remote host closed the connection]
Buggerbunny has joined #systemtap
<Buggerbunny> Hey, hey. Can I see which memory regions change with systemtap? Like a memory scanner?
<fche> hi Buggerbunny
<fche> there is a kernel-side probe that relates to this: kernel.data("SYMBOL_NAME").wrote or kernel.data(0xaddr).write
<fche> see [man stapprobes]
<fche> and also: if you can identify other times that mark boundaries for when you want to detect changes across
<fche> like say syscalls
<fche> you can have a pair of probes, one to save the memory value in a systemtap variable
<fche> and another one to compare the saved value to the current one
<fche> and the latter one can print a message if it finds a change
<Buggerbunny> Right now I’m using GameConqueror but it’s not that great.
<fche> nothing is that great :(
<fche> is it userspace memory you want to monitor ?
<Buggerbunny> Yeah!
<Buggerbunny> Windows has this programm called Cheat Engine, that’s what I’m really looking for.
<fche> have you tried gdb hardware watchpoints ?
<Buggerbunny> Not yet, no.
irker620 has quit [Quit: transmission timeout]
<Buggerbunny> Wow, it workes but I’ve used GameConqueror. What a freaking pain in the ass.
<Buggerbunny> And then the adress will change once the programm restarts.
<fche> if the address can be computed at run time from symbol addresses or variable contents, yeah a gdb command script (or even gdb/python script) may be your best bet
<Buggerbunny> Then you have to compile gdb with python support.
<fche> that's common
<fche> but gdb also has its own little command language that can do quite a bit
<fche> the only reason I'm not harping on systemtap here is because the data page-change monitoring facility it supports (that the kernel exposes through an internal API) is for kernel-space only IIRC
<fche> so it wouldn't help you here
<fche> so you'd have to do it with some manual load/save + load/compare probe pairs
<Buggerbunny> Need to read the manual of gdb since it’s a somewhat complex topic but anyway, thanks a lot for your help! :)
<fche> no problemo, good luck!
<Buggerbunny> Systemtap would be a lot better for this kind of stuff since it’s undetectable to the program.
<fche> well, nothing is completely undetectable
<Buggerbunny> Yeah, but it’s flies pretty low!
<fche> running it in a carefully configured VM, and monitoring that VM by systemtap running on the host ... that could be another cunning approach
<fche> My orders came through. My squadron ships out tomorrow. We're bombing the storage depots at Daiquiri at 1800 hours. We're coming in from the north, below their radar
<Buggerbunny> Having that clunky gdb attached to your program in comparison is a whole different world.
<fche> aha
<fche> but gdb can also be attached to a kvm vm
<fche> or valgrind :)
<Buggerbunny> You know systemtap is great!
<fche> you are SO RIGHT :-)
<fche> so would be glad to help you with it in greater detail ....
<fche> .... but ..............
<fche> it's 10:45pm here and I'm being summoned by droopy eyelids
<Buggerbunny> It’s almost 5 am here.
<Buggerbunny> Good night!
<fche> techies are a looney lot
<fche> feel free to email me or the list (better) with findings / questions
orivej has joined #systemtap
Buggerbunny has quit [Quit: Lock the door on your way out!]
orivej has quit [Ping timeout: 265 seconds]
<agentzh> re running it in a carefully configured VM, and monitoring that VM by systemtap running on the host
<agentzh> yeah, we're trying to do that with stap :)
<agentzh> fche: re the patch for proc_mem_rss(), i've noted that it fails to work with older kernels. this followup fix makes it work with centos 7/6 at least: https://gist.github.com/agentzh/565739130904ae7590547c2050d397f5
<agentzh> wondering if there's a way to check if enum constants exist in the current kernel (like MM_SHMEMPAGES). hopefully we don't have to use stapconf.h for this.
<agentzh> any suggestions on this would help make my followup fix patch above complete :)
_whitelogger has joined #systemtap
khaled has joined #systemtap
orivej has joined #systemtap
khaled has quit [Remote host closed the connection]
khaled has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #systemtap
lindi- has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #systemtap
<fche> would probably require a stapconf
_whitelogger has joined #systemtap
LW_ has quit [Remote host closed the connection]
LW_ has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #systemtap
<agentzh> fche: yeah, the latter #ifdef approach works for macros. but unfortunately the current case is an enum const.
<agentzh> i'll do the stapconf thing for this then. but i'm about to board my flight soon. so will take some more time.
<fche> yeah
<agentzh> the official 3.10 kernel does not have that MM_SHMEMPAGES enum const.
<agentzh> redhat's centos 7's kernel hacked it in.
<fche> that happens
<agentzh> it got me confused at first until i checked out redhat's src.rpm.
<fche> stap should probably learn to resolve $foo where foo is an enum symbol
<agentzh> yeah, that would be very handy.
<fche> and then it could be conditionalized with the usual if(@defined(...))
<agentzh> but it would require dwarf then.
<agentzh> sad that @const() in stap is currently for something else.
<agentzh> the C src level constant.
<agentzh> or enum consts are in kallsyms?
<fche> nope
<fche> dwarf
<agentzh> alas.
<agentzh> then not for dwarfless use cases.
<agentzh> it's still useful for the dwarf case anyway :)
<agentzh> there's another quick question.
<agentzh> i wonder if we can have an efficient way to check if a mem page is indeed loaded into the target user process.
<agentzh> currently i'm doing the try { user_long() } way, which is very inefficient.
<agentzh> though it works.
<fche> hm try { user_int(0xaddress) } catch ....
<fche> er yea
<fche> inefficient how?
* agentzh has many mem pages to test.
<agentzh> continguous mem pages.
<agentzh> so maybe it's more efficient to simply walk down some mm data strucutres?
<agentzh> like tlb?
<fche> tlb is not what you're looking for
<fche> page tables, ... yeah but those need locking etc.
<agentzh> oh yeah, sorry i mean page tables.
<agentzh> hmm, locking is indeed a problem.
<agentzh> the target process is paused when the probe handler is running anyway?
<fche> -task- (thread)
<agentzh> ah, okay, multithreading
<agentzh> any other hopes?
<agentzh> maybe some trimmed down way for try { user_int }?
<agentzh> some lean primitive i guess?
zodbot has quit [Quit: Quick restart]
<fche> don't think there's an obvious low level one that'd be much more efficient than this try/user*/catch
<agentzh> okay, then it would only save a dozen cycles per page.
zodbot has joined #systemtap
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 240 seconds]