fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
hpt has quit [Ping timeout: 258 seconds]
hpt has joined #systemtap
_whitelogger has joined #systemtap
yog_ has joined #systemtap
sscox has joined #systemtap
tonyj has quit [Remote host closed the connection]
tonyj has joined #systemtap
orivej has quit [Ping timeout: 246 seconds]
hpt has quit [Ping timeout: 246 seconds]
mjw has joined #systemtap
gromero has quit [Ping timeout: 252 seconds]
orivej has joined #systemtap
gromero has joined #systemtap
mjw has quit [Quit: Leaving]
mjw has joined #systemtap
<gromero> fche: morning
<gromero> so, I talked to the kernel folks and the said:
<gromero> @gromero so we *always* save the state when we take the process off a CPU.
<gromero> > it's only when we start a process (ie restore) that we may do lazily
<gromero> > so if the process is off a cpu (ie. has gone through __switch_to()) fp_state in memory should be the currect process state
<gromero> then, I'm really lost why I can't get the correct values using current->thread->fp_state after do_notify_resume, just before entering the stap probe
<gromero> :/
<fche> AIUI switch-to is a relatively late stage processing
<fche> maybe they don't quite get that the stap probes run at some intermediate stage of context switching / exception handling, not precisely at syscall boundaries
<fche> so
<fche> if the tapset embedded-c function does a giveup_all() or equivalent
<fche> can it then access the fpregs in the task_struct properly ?
<gromero> I'll try, but giveup_all will basically flush from live registers to the thread->fp_state, so I'm not sure I'll be in the right context to flush the lives
<gromero> process seems to be not passing through __switch_to with FP facility enabled ...
<gromero> i.e. in the test case __switch_to is only called at the very beginning of the process
<fche> did you have a chance to test the giveup_all() call in that tapset function context?
<gromero> fche: compilation can't find it:
<gromero> /tmp/staptSjKkl/stap_44763_src.c: In function ‘function___global__stp_get_register_by_offset__overload_0’:
<gromero> giveup_all();
<gromero> /tmp/staptSjKkl/stap_44763_src.c:1919:2: error: implicit declaration of function ‘giveup_all’ [-Werror=implicit-function-declaration]
<gromero> ^~~~~~~~~~
<gromero> I'm calling it just before I call a printk()
<gromero> it should work so I guess
<fche> it's exported, so should just need the decl from some header file
<gromero> ok
<fche> <asm/switch_to.h> ?
<gromero> yep
<gromero> tried that but didn't work ...
<gromero> I added to %{ }
<gromero> at the beginning o .stp
<gromero> is that correct?
<fche> yeah, (post diff?)
<fche> but the decl is pretty straight void giveup_all(struct task_struct *tsk) at least in the current kernel
<gromero> fche: sorry, my bad, I missed "%" in %}
<gromero> yeah
<gromero> it looks calling giveup_all
<gromero> with:
<gromero> + giveup_all(current);
<gromero> in the register.stp
<gromero> it *works* calling giveup_all
<gromero> let me see if can do some clean up from yesterday and get it in a better shape
<gromero> brb
<fche> righto
<fche> hurray
sapatel has joined #systemtap
orivej has quit [Ping timeout: 245 seconds]
irker603 has joined #systemtap
<irker603> systemtap: sapatel systemtap.git:refs/heads/sapatel/pr23285 * release-4.1-43-g68846b9 / bpf-translate.cxx: added looping listener thread but, multiple writes happening for single read http://tinyurl.com/y5kzpvuo
Amy_ has quit [Ping timeout: 259 seconds]
Amy_ has joined #systemtap
<gromero> fche: yeah o/ it really seems to work fine
<gromero> I pushed some drafts on the patch, test, and probe here:
<fche> looking
<gromero> yep, please let me know what you think
<gromero> I'm heading to grab some food and a meeting after
<gromero> bbiab
<fche> gromero, looks pretty plausible. I'd try to find some way of making that 1000 number a symbol
orivej has joined #systemtap
lindi- has quit [Ping timeout: 252 seconds]
<gromero> fche: thanks a lot for a first review
<gromero> I'll make 1000 as a symbol
<gromero> I think that instead calling giveup_all() it's possible to read the register directly from the CPU since they are live and hot (giveup_all() basically flush them to thread and we use them back for the tap)
<gromero> but on the other hand giveup_all() will take care of enabling MSR_FP & friends so we don't get an exception in the kernel if FP & fiends facility are disabled
<gromero> so I believe it's ok for now
<gromero> I'll check how tests are organized in systemtap and incorporate a more complete test for the floating regs on PPC64
<gromero> and also fix the reference manuals, is necessary - I didn't check it carefully yet
<fche> ok
lindi- has joined #systemtap
amerey has joined #systemtap
khaled has joined #systemtap
<gromero> fche: what's the preferred way to run the tests in testsuite?
<gromero> I'm getting a missing 'runtest': https://pastebin.com/raw/qK1gCGjy
<sapatel> gromero, navigate to ~/systemtap/build and then run $make check
<sapatel> sorry navigate to ~/stap/build **
<gromero> sapatel: you mean the repo root dir?
<gromero> like in:
<gromero> gromero@2q14gto1:~/git/systemtap$ pwd
<gromero> /home/gromero/git/systemtap
<gromero> gromero@2q14gto1:~/git/systemtap$ git remote -vv
<sapatel> I think you need to make a build folder
<gromero> ah, it's like gcc & friends okay
<gromero> btw, is there a way to run a single specific test found in /testsuite/systemtap.base ?
<sapatel> yes
<gromero> I don't want to run all the suite
<sapatel> $make installcheck RUNTESTFLAGS=yourtest.exp
<gromero> sapatel: tks!
amerey has quit [Quit: Leaving]
irker603 has quit [Quit: transmission timeout]
<fche> runtest is a part of dejagnu
<fche> thanks sapatel
sapatel has quit [Remote host closed the connection]
DUKENUKEM has quit [Ping timeout: 246 seconds]
DUKENUKEM has joined #systemtap