[PATCH v3 08/13] ARM: ftrace: enable the graph tracer with the EABI unwinder

[Ard Biesheuvel]

On Thu, 3 Feb 2022 at 10:17, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Thu, Feb 3, 2022 at 9:21 AM Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > Enable the function graph tracer in combination with the EABI unwinder,
> > so that Thumb2 builds or Clang ARM builds can make use of it.
> >
> > This involves using the unwinder to locate the return address of an
> > instrumented function on the stack, so that it can be overridden and
> > made to refer to the ftrace handling routines that need to be called at
> > function return.
> >
> > Given that for these builds, it is not guaranteed that the value of the
> > link register is stored on the stack, fall back to the stack slot that
> > will be used by the ftrace exit code to restore LR in the instrumented
> > function's execution context.
> >
> > Signed-off-by: Ard Biesheuvel <ardb at kernel.org>
> > Reviewed-by: Steven Rostedt (Google) <rostedt at goodmis.org>
>
> > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > index 07055a503022..cc7523f44be4 100644
> > --- a/arch/arm/Kconfig.debug
> > +++ b/arch/arm/Kconfig.debug
> > @@ -65,7 +65,7 @@ config UNWINDER_FRAME_POINTER
> >
> >  config UNWINDER_ARM
> >         bool "ARM EABI stack unwinder"
> > -       depends on AEABI && !FUNCTION_GRAPH_TRACER
> > +       depends on AEABI
> >         # https://github.com/ClangBuiltLinux/linux/issues/732
> >         depends on !LD_IS_LLD || LLD_VERSION >= 110000
> >         select ARM_UNWIND
>
> What are the remaining tradeoffs between the two unwinders
> on EABI kernels?

The frame pointer based stack tracer dumps the values of the registers
at each level, by decoding the instructions that push them onto the
stack in the prologue. And the frame pointer unwinder is generally a
bit more robust.

> Since we require llvm-11 as the minimum
> toolchain now, we can probably drop the LLD_VERSION
> check here as well, so UNWINDER_ARM should finally work
> for any EABI kernel.
>

Indeed.

> According to the help text, the main downside is a small size
> increase that I've measured at under 1% in multi_v7_defconfig,
> however that seems to be far outweighed by allowing thumb2
> kernels that reduce the size by 15% in the same config.
>

Yeah the EABI format unwind info is a bit more compact than DWARF, so
the size is manageable. I saw a ~30% reduction in .text size, so 15%
for the core kernel is probably accurate, but it is likely a bit
better for modules (modulo the rounding to page size, of course)

> Are there any other reasons for keeping the frame pointer
> unwinder as a normal option for ARMv7?
>

Just the points mentioned above