On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
On 25/07/16 18:13, Catalin Marinas wrote:
You get more unexpected side effects by not saving/restoring the whole
stack. We looked into this on Friday and came to the conclusion that
there is no safe way for kprobes to know which arguments passed on the
stack should be preserved, at least not with the current API.
Basically the AArch64 PCS states that for arguments passed on the stack
(e.g. they can't fit in registers), the caller allocates memory for them
(on its own stack) and passes the pointer to the callee. Unfortunately,
the frame pointer seems to be decremented correspondingly to cover the
arguments, so we don't really have a way to tell how much to copy.
Copying just the caller's stack frame isn't safe either since a
callee/caller receiving such argument on the stack may passed it down to
a callee without copying (I couldn't find anything in the PCS stating
that this isn't allowed).
The PCS seems (at least to me) to be pretty clear that "the
address of the first stacked argument is defined to be the initial
value of SP".
I think it is only the return value (when stacked via the x8
pointer) that can be passed through an intermediate function in the
way described above. Isn't it OK for a jprobe to clobber this
memory? The underlying function will overwrite whatever the jprobe
put there anyway.
Am I overlooking some additional detail in the PCS?
I suspect that the "initial value of SP" is simply meant to be relative to the
base of the region of stack reserved for callee parameters. While it also uses
the phrase "current stack-pointer value", I suspect that this is overly
In practice, GCC allocates callee parameters *above* the frame record> <snip>
for the caller, which is above the SP and FP. e.g. with:
4005d0: f81f0ff3 str x19, [sp,#-16]!
4005d4: aa0003f3 mov x19, x0
4005d8: f9400260 ldr x0, [x19]
4005dc: f84107f3 ldr x19, [sp],#16
4005e0: d65f03c0 ret