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:
<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?