On Mon, 8 Mar 2021 11:52:10 +0900
Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
> So, here is my idea;
>
> 1) Change the trampline code to prepare stack frame at first and save
> registers on it, instead of "push". This will makes ORC easy to setup
> stackframe information for this code.
> 2) change the return addres fixup timing. Instead of using return value
> of trampoline handler, before removing the real return address from
> current->kretprobe_instances.
> 3) Then, if orc_find() finds the ip is in the kretprobe_trampoline, it
> checks the contents of the end of stackframe (at the place of regs->sp)
> is same as the address of it. If it is, it can find the correct address
> from current->kretprobe_instances. If not, there is a correct address.
Another trickly idea is put a call on top of kretprobe_trampoline like this.
"__kretprobe_trampoline:\n"
" call kretprobe_trampoline\n"
"kretprobe_trampoline:\n"
" pushq %rsp\n"
" pushfq\n"
SAVE_REGS_STRING
" movq %rsp, %rdi\n"
" call trampoline_handler\n"
/* Replace __kretprobe_trampoline with true return address. */
" movq %rax, 20*8(%rsp)\n"
RESTORE_REGS_STRING
" popfq\n"
" popq %rsp\n"
" ret\n"
This will leave a marker (kretprobe_trampoline or __kretprobe_trampoline+5) on
the top of stack, and the stack frame seems like a normal function. If objtool
can make an ORC info by disassembling kretprobe_trampoline, I guess it is
easy to make a stack frame information.
But anyway, from the inside of target function, it still see "__kretprobe_trampoline"
on the stack instead of caller_func, so orc_kretprobe_find() is still needed.
I'm not familier with the UNWIND_HINT macro, so if it is easy to handle the original
case, I think my first idea will be better.
Thank you,
--
Masami Hiramatsu <mhiramat@xxxxxxxxxx>
