From: Mark Rutland <mark.rutland@arm.com> To: Changbin Du <changbin.du@gmail.com> Cc: rostedt@goodmis.org, linux@armlinux.org.uk, x86@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] fgraph: record function return value Date: Mon, 14 Jan 2019 12:11:56 +0000 [thread overview] Message-ID: <20190114121151.GC10258@lakrids.cambridge.arm.com> (raw) In-Reply-To: <20190112065701.30841-1-changbin.du@gmail.com> On Sat, Jan 12, 2019 at 02:57:01PM +0800, Changbin Du wrote: > This patch adds a new trace option 'funcgraph-retval' and is disabled by > default. When this option is enabled, fgraph tracer will show the return > value of each function. This is useful to find/analyze a original error > source in a call graph. > > One limitation is that kernel doesn't know the prototype of functions. So > fgraph assumes all functions have a retvalue of type int. You must ignore > the value of *void* function. And if the retvalue looks like an error code > then both hexadecimal and decimal number are displayed. This sounds more confusing than helpful, and it sounds like this has overlap with FTRACE_WITH_REGS functionality. > diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S > index 81b8eb5c4633..223f4ad269d4 100644 > --- a/arch/arm64/kernel/entry-ftrace.S > +++ b/arch/arm64/kernel/entry-ftrace.S > @@ -202,6 +202,7 @@ ENTRY(return_to_handler) > stp x4, x5, [sp, #32] > stp x6, x7, [sp, #48] > > + mov x1, x0 // return value > mov x0, x29 // parent's fp > bl ftrace_return_to_handler// addr = ftrace_return_to_hander(fp); > mov x30, x0 // restore the original return address What about indirect return values? Those go via x8. Additionally, in some cases (e.g. static functions with cross-function optimization), the compiler might not follow the usual PCS, so the return value might not be in x0 regardless. Maybe such functions aren't hooked by ftrace today? Generally, I don't think that this is going to be reliable. > +config HAVE_FTRACE_RETVAL > + bool > + > config HAVE_DYNAMIC_FTRACE > bool > help > @@ -160,6 +163,7 @@ config FUNCTION_GRAPH_TRACER > depends on HAVE_FUNCTION_GRAPH_TRACER > depends on FUNCTION_TRACER > depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE > + select HAVE_FTRACE_RETVAL if (X86 || ARM) ... but not arm64? Thanks, Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Changbin Du <changbin.du@gmail.com> Cc: linux-doc@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] fgraph: record function return value Date: Mon, 14 Jan 2019 12:11:56 +0000 [thread overview] Message-ID: <20190114121151.GC10258@lakrids.cambridge.arm.com> (raw) In-Reply-To: <20190112065701.30841-1-changbin.du@gmail.com> On Sat, Jan 12, 2019 at 02:57:01PM +0800, Changbin Du wrote: > This patch adds a new trace option 'funcgraph-retval' and is disabled by > default. When this option is enabled, fgraph tracer will show the return > value of each function. This is useful to find/analyze a original error > source in a call graph. > > One limitation is that kernel doesn't know the prototype of functions. So > fgraph assumes all functions have a retvalue of type int. You must ignore > the value of *void* function. And if the retvalue looks like an error code > then both hexadecimal and decimal number are displayed. This sounds more confusing than helpful, and it sounds like this has overlap with FTRACE_WITH_REGS functionality. > diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S > index 81b8eb5c4633..223f4ad269d4 100644 > --- a/arch/arm64/kernel/entry-ftrace.S > +++ b/arch/arm64/kernel/entry-ftrace.S > @@ -202,6 +202,7 @@ ENTRY(return_to_handler) > stp x4, x5, [sp, #32] > stp x6, x7, [sp, #48] > > + mov x1, x0 // return value > mov x0, x29 // parent's fp > bl ftrace_return_to_handler// addr = ftrace_return_to_hander(fp); > mov x30, x0 // restore the original return address What about indirect return values? Those go via x8. Additionally, in some cases (e.g. static functions with cross-function optimization), the compiler might not follow the usual PCS, so the return value might not be in x0 regardless. Maybe such functions aren't hooked by ftrace today? Generally, I don't think that this is going to be reliable. > +config HAVE_FTRACE_RETVAL > + bool > + > config HAVE_DYNAMIC_FTRACE > bool > help > @@ -160,6 +163,7 @@ config FUNCTION_GRAPH_TRACER > depends on HAVE_FUNCTION_GRAPH_TRACER > depends on FUNCTION_TRACER > depends on !X86_32 || !CC_OPTIMIZE_FOR_SIZE > + select HAVE_FTRACE_RETVAL if (X86 || ARM) ... but not arm64? Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-14 12:12 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-12 6:57 [PATCH] fgraph: record function return value Changbin Du 2019-01-12 6:57 ` Changbin Du 2019-01-12 12:21 ` Matthew Wilcox 2019-01-12 12:21 ` Matthew Wilcox 2019-01-12 14:20 ` Changbin Du 2019-01-12 14:20 ` Changbin Du 2019-01-14 12:11 ` Mark Rutland [this message] 2019-01-14 12:11 ` Mark Rutland 2019-01-14 16:07 ` Changbin Du 2019-01-14 16:07 ` Changbin Du 2019-01-14 16:21 ` Steven Rostedt 2019-01-14 16:21 ` Steven Rostedt 2019-01-15 0:40 ` Changbin Du 2019-01-15 0:40 ` Changbin Du
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190114121151.GC10258@lakrids.cambridge.arm.com \ --to=mark.rutland@arm.com \ --cc=changbin.du@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=rostedt@goodmis.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.