The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: Jeremy Fertic <jeremyfertic@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Russell King <linux@armlinux.org.uk>,
	rostedt@goodmis.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: ARM: config issue with ftrace function graph tracer
Date: Sun, 13 Jan 2019 16:41:52 +0100	[thread overview]
Message-ID: <d9bc5937c5fc7a45f3aca14fdf68803d@agner.ch> (raw)
In-Reply-To: <20190112010139.GA5288@r2700x.localdomain>

Hi,

On 12.01.2019 02:01, Jeremy Fertic wrote:
> I'm having a problem with the ftrace function graph tracer on a 32 bit arm
> board (orangepi pc). A bisect points to the following commit:
> 
> f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
> 
> Before this commit, if I use sunxi_defconfig and then menuconfig to enable
> FTRACE and FUNCTION_TRACER then the function graph tracer works. With this
> commit, and as of v5.0-rc1, doing the same as above results in a broken
> function graph tracer and often an oops as well. The commit introduces a
> choice group and it looks like it should default to UNWINDER_FRAME_POINTER
> if FUNCTION_GRAPH_TRACER is enabled. FUNCTION_GRAPH_TRACER is enabled by
> default when I enable FUNCTION_TRACER but this has no effect on the choice.
> The choice always defaults to the other option which is UNWINDER_ARM. If I
> manually choose UNWINDER_FRAME_POINTER then the function graph tracer works
> fine.

The default selection is there, but this is made at "make
sunxi_defconfig" time. At this point FUNCTION_GRAPH_TRACER is not
enabled, hence Kconfig uses UNWIDER_ARM. However, when enabling the
FUNCTION_GRAPH_TRACER Kconfig will _not_ reconsider and switch enable
UNWINDER_FRAME_POINTER.

Before that commit, when enabling FUNCTION_GRAPH_TRACER, we simply also
enabled FRAME_POINTER...

I guess we need to make sure that FUNCTION_GRAPH_TRACER depends on the
UNWINDER_FRAME_POINTER choice. There is already a similar dependency
with THUMB2_KERNEL. We can cleanup that dependency since
UNWINDER_FRAME_POINTER already depends on !THUMB2_KERNEL.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 664e918e2624..a2ac65a8b2cc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,7 +69,7 @@ config ARM
        select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K ||
CPU_V7) && MMU
        select HAVE_EXIT_THREAD
        select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
-       select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL
+       select HAVE_FUNCTION_GRAPH_TRACER if UNWINDER_FRAME_POINTER
        select HAVE_FUNCTION_TRACER if !XIP_KERNEL
        select HAVE_GCC_PLUGINS
        select HAVE_GENERIC_DMA_COHERENT
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 6d6e0330930b..8341649fa71d 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -47,8 +47,8 @@ config DEBUG_WX

 choice
        prompt "Choose kernel unwinder"
-       default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
-       default UNWINDER_FRAME_POINTER if !AEABI ||
FUNCTION_GRAPH_TRACER
+       default UNWINDER_ARM if AEABI
+       default UNWINDER_FRAME_POINTER if !AEABI
        help
          This determines which method will be used for unwinding kernel
stack
          traces for panics, oopses, bugs, warnings, perf,
/proc/<pid>/stack,


> 
> Any idea why the default behaviour has changed?

The rational is stated in the commit message, the main reason was to
disallow UNWINDER_FRAME_POINTER in case Clang is used (since Clang does
not create the expected function prologue).

The choice also aligns with how unwinders are selected on x86.

--
Stefan

  reply	other threads:[~2019-01-13 15:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-12  1:01 ARM: config issue with ftrace function graph tracer Jeremy Fertic
2019-01-13 15:41 ` Stefan Agner [this message]
2019-01-13 16:14   ` Russell King - ARM Linux
2019-01-15 22:37     ` Stefan Agner

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=d9bc5937c5fc7a45f3aca14fdf68803d@agner.ch \
    --to=stefan@agner.ch \
    --cc=arnd@arndb.de \
    --cc=jeremyfertic@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rostedt@goodmis.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox