Re: [PATCH 02/16] perf: Unified API to record selective sets of archregisters
From: Jiri Olsa
Date: Wed May 02 2012 - 08:59:02 EST
SNIP
> >
> > I just sent v3, with changed design to be more generic, please check
> >
> > anyway, currently there's no way to mix 32 and 64 bit registers in sample.
> >
> > As I mentioned above, once running compat task, 64 bit registers
> > are stored anyway. Given that all 32 bit registers have 64 equiv.
> > you can ask to store RAX|RBX|R15.
> >
> Well, R8-R15 do not exist in 32-bit mode. So I wonder what is saved
> on the stack for those, probably nothing. And in that case, how do you
> handle the case where the user asked for R15 but it is not available and
> you know that only on PMU interrupt.
right, R8-R15 do not exist in 32 bit mode, meaning that the 32 bit task
do not use them... but when you enter 64 bit kernel from 32 bit compat
task, still 64bits registers are saved.. as for native 64 process,
there's no difference.. so even for 32 bit task you get 64 bits
registers described below.
The availbility of registers is tricky for user space register dump.
We dump whatever we got in pt_regs structure from perf_sample_regs_user.
The problem is, that exception do not store all of the registers.. the rest
of the registers is whatever is in stack occupying the pt_regs space.
When kernel is entered (by exception or irq), following is saved by CPU
(both 32 and 64 bits):
ss, sp, flags, cs ip
followed by SAVE_ARGS (for exception):
movq_cfi rdi, 8*8
movq_cfi rsi, 7*8
movq_cfi rdx, 6*8
.if \save_rcx
movq_cfi rcx, 5*8
.endif
movq_cfi rax, 4*8
.if \save_r891011
movq_cfi r8, 3*8
movq_cfi r9, 2*8
movq_cfi r10, 1*8
movq_cfi r11, 0*8
SAVE_REST - saves the whole pt_regs structure just for the
sake of the syscall_trace_enter function, once finished it's
poped out..
As for unwind we should get the most important ones. Of course
the unwind could be based on any register, and with bogus value
the unwind just stops.
I think we are in better shape for irqs but I'd need to check.
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/