From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 44C1437155; Wed, 8 Nov 2023 23:14:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JyHigs05" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BF50C433C8; Wed, 8 Nov 2023 23:14:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699485298; bh=xVGspZHqa7ebm1mR2Tje10arpm85obbIl39AN2mQJ3M=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JyHigs05zwlZLjVYeubaXm76pgBss7x0rTEEg8qQq5pvGqxmVPH8K+1b/U5iPjLMF eq80OH7wQ7WcCeUGl9LwR2wNjaK2n+kvxggmWu2utzB12SevBs2Qrjl2CzX7uSgGCX gEVvso4TBccpElYNkwz71aghzlGy6GtS5zKIErjkCNdcH4OUas2lT7WB2DYdOhucqB c4pG7oF1s7g6FW3EsFteIUDJhSQCSDk0qK8/GoXOf+ayLcO5szMUeW+3MERQqYvsT4 F/PACmNXnItGac+sb/EhotsiimmtwlysRckjNgFkSx9grT2nodbj0UJ6A0dl9e0BA3 PcbkbI58gTazA== Date: Thu, 9 Nov 2023 08:14:52 +0900 From: Masami Hiramatsu (Google) To: "Masami Hiramatsu (Google)" Cc: Alexei Starovoitov , Steven Rostedt , Florent Revest , linux-trace-kernel@vger.kernel.org, LKML , Martin KaFai Lau , bpf , Sven Schnelle , Alexei Starovoitov , Jiri Olsa , Arnaldo Carvalho de Melo , Daniel Borkmann , Alan Maguire , Mark Rutland , Peter Zijlstra , Thomas Gleixner , Guo Ren Subject: Re: [RFC PATCH v2 01/31] tracing: Add a comment about ftrace_regs definition Message-Id: <20231109081452.fd6e091df9df1bc7c5ced38b@kernel.org> In-Reply-To: <169945347160.55307.1488323435914144870.stgit@devnote2> References: <169945345785.55307.5003201137843449313.stgit@devnote2> <169945347160.55307.1488323435914144870.stgit@devnote2> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 8 Nov 2023 23:24:32 +0900 "Masami Hiramatsu (Google)" wrote: > From: Masami Hiramatsu (Google) > > To clarify what will be expected on ftrace_regs, add a comment to the > architecture independent definition of the ftrace_regs. > > Signed-off-by: Masami Hiramatsu (Google) > --- > Changes in v2: > - newly added. > --- > include/linux/ftrace.h | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h > index e8921871ef9a..b174af91d8be 100644 > --- a/include/linux/ftrace.h > +++ b/include/linux/ftrace.h > @@ -118,6 +118,31 @@ extern int ftrace_enabled; > > #ifndef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS > > +/** > + * ftrace_regs - ftrace partial/optimal register set > + * > + * ftrace_regs represents a group of registers which is used at the > + * function entry and exit. There are three types of registers. > + * > + * - Registers for passing the parameters to callee, including the stack > + * pointer. (e.g. rcx, rdx, rdi, rsi, r8, r9 and rsp on x86_64) > + * - Registers for passing the return values to caller. > + * (e.g. rax and rdx on x86_64) > + * - Registers for hooking the function return including the frame pointer > + * (the frame pointer is architecture/config dependent) > + * (e.g. rbp and rsp for x86_64) Oops, I found the program counter/instruction pointer must be saved too. This is used for live patching. One question is that if the IP is modified at the return handler, what should we do? Return to the specified address? Thanks, > + * > + * Also, architecture dependent fields can be used for internal process. > + * (e.g. orig_ax on x86_64) > + * > + * On the function entry, those registers will be restored except for > + * the stack pointer, so that user can change the function parameters. > + * On the function exit, onlu registers which is used for return values > + * are restored. > + * > + * NOTE: user *must not* access regs directly, only do it via APIs, because > + * the member can be changed according to the architecture. > + */ > struct ftrace_regs { > struct pt_regs regs; > }; > -- Masami Hiramatsu (Google)