Prev: [PATCH 0/15 V10] Work to enable SmartMedia/xD support in mtd
Next: [PATCH v2 10/12] ACPI: processor: refactor internal map_lsapic_id()
From: Frederic Weisbecker on 22 Feb 2010 14:10
On Sun, Feb 14, 2010 at 01:18:32AM +0530, Rabin Vincent wrote:
> With a new enough GCC, ARM function tracing can be supported without the
> need for frame pointers. This is essential for Thumb-2 support, since
> frame pointers aren't available then.
>
> Signed-off-by: Rabin Vincent <rabin(a)rab.in>
> ---
> arch/arm/Kconfig.debug | 5 +++++
> arch/arm/kernel/armksyms.c | 2 ++
> arch/arm/kernel/entry-common.S | 7 +++++++
> kernel/trace/Kconfig | 2 +-
> 4 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 5cb9326..5501253 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -27,6 +27,11 @@ config ARM_UNWIND
> the performance is not affected. Currently, this feature
> only works with EABI compilers. If unsure say Y.
>
> +config OLD_MCOUNT
> + bool
> + depends on FUNCTION_TRACER && FRAME_POINTER
> + default y
> +



Btw, you described that mcount is used in some gcc versions and
__gnu_mcount_nc in newers.
Shouldn't we have a gcc version dependency here? (not sure we can
do this from Kconfig though).



> config DEBUG_USER
> bool "Verbose user fault messages"
> help
> diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
> index 8214bfe..e5e1e53 100644
> --- a/arch/arm/kernel/armksyms.c
> +++ b/arch/arm/kernel/armksyms.c
> @@ -165,6 +165,8 @@ EXPORT_SYMBOL(_find_next_bit_be);
> #endif
>
> #ifdef CONFIG_FUNCTION_TRACER
> +#ifdef CONFIG_OLD_MCOUNT
> EXPORT_SYMBOL(mcount);
> +#endif
> EXPORT_SYMBOL(__gnu_mcount_nc);
> #endif
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index d412d7c..c98e3a3 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -169,6 +169,12 @@ gnu_trace:
> ldmia sp!, {r0-r3, ip, lr}
> mov pc, ip
>
> +#ifdef CONFIG_OLD_MCOUNT
> +/*
> + * This is under an ifdef in order to force link-time errors for people trying
> + * to build with !FRAME_POINTER with a GCC which doesn't use the new-style
> + * mcount.
> + */
> ENTRY(mcount)
> stmdb sp!, {r0-r3, lr}
> ldr r0, =ftrace_trace_function
> @@ -187,6 +193,7 @@ trace:
> mov pc, r2
> ldr lr, [fp, #-4] @ restore lr
> ldmia sp!, {r0-r3, pc}
> +#endif
>
> #endif /* CONFIG_DYNAMIC_FTRACE */
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index 6c22d8a..7468ffe 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -126,7 +126,7 @@ if FTRACE
> config FUNCTION_TRACER
> bool "Kernel Function Tracer"
> depends on HAVE_FUNCTION_TRACER
> - select FRAME_POINTER
> + select FRAME_POINTER if (!ARM_UNWIND)


So, if I understand well. If people have ARM_UNWIND but
FUNCTION_TRACER, it might crash at link time in case
they don't have a recent enough gcc version to
support the new -pg style?

That doesn't look good.

Ideally, we need HAVE_FUNCTION_TRACER to be enabled in arm
only if (old gcc && frame pointers) || new gcc

And then, we need config OLD_MCOUNT:
old gcc && FUNCTION_TRACER

and config NEW_MCOUNT:
new gcc && FUNCTION_TRACER

so that we can selectively build mcount or __gnu_mcount_nc.

Hmm, I fear we can't check gcc version from Kconfig, as I'm
grepping on Kconfig files...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 23 Feb 2010 12:20
On Tue, Feb 23, 2010 at 08:18:33AM -0500, Steven Rostedt wrote:
> On Mon, 2010-02-22 at 20:05 +0100, Frederic Weisbecker wrote:
>
> >
> > Btw, you described that mcount is used in some gcc versions and
> > __gnu_mcount_nc in newers.
> > Shouldn't we have a gcc version dependency here? (not sure we can
> > do this from Kconfig though).
> >
>
> Maybe we can add something to recordmcount.pl?



May be yeah, with an explicit message that describes the issue.



> >
> >
> > > config DEBUG_USER
> > > bool "Verbose user fault messages"
> > > help
> > > diff --git a/arch/arm/kernel/armksyms.c b/arch/arm/kernel/armksyms.c
> > > index 8214bfe..e5e1e53 100644
> > > --- a/arch/arm/kernel/armksyms.c
> > > +++ b/arch/arm/kernel/armksyms.c
> > > @@ -165,6 +165,8 @@ EXPORT_SYMBOL(_find_next_bit_be);
> > > #endif
> > >
> > > #ifdef CONFIG_FUNCTION_TRACER
> > > +#ifdef CONFIG_OLD_MCOUNT
> > > EXPORT_SYMBOL(mcount);
> > > +#endif
> > > EXPORT_SYMBOL(__gnu_mcount_nc);
> > > #endif
> > > diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> > > index d412d7c..c98e3a3 100644
> > > --- a/arch/arm/kernel/entry-common.S
> > > +++ b/arch/arm/kernel/entry-common.S
> > > @@ -169,6 +169,12 @@ gnu_trace:
> > > ldmia sp!, {r0-r3, ip, lr}
> > > mov pc, ip
> > >
> > > +#ifdef CONFIG_OLD_MCOUNT
> > > +/*
> > > + * This is under an ifdef in order to force link-time errors for people trying
> > > + * to build with !FRAME_POINTER with a GCC which doesn't use the new-style
> > > + * mcount.
> > > + */
> > > ENTRY(mcount)
> > > stmdb sp!, {r0-r3, lr}
> > > ldr r0, =ftrace_trace_function
> > > @@ -187,6 +193,7 @@ trace:
> > > mov pc, r2
> > > ldr lr, [fp, #-4] @ restore lr
> > > ldmia sp!, {r0-r3, pc}
> > > +#endif
> > >
> > > #endif /* CONFIG_DYNAMIC_FTRACE */
> > >
> > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> > > index 6c22d8a..7468ffe 100644
> > > --- a/kernel/trace/Kconfig
> > > +++ b/kernel/trace/Kconfig
> > > @@ -126,7 +126,7 @@ if FTRACE
> > > config FUNCTION_TRACER
> > > bool "Kernel Function Tracer"
> > > depends on HAVE_FUNCTION_TRACER
> > > - select FRAME_POINTER
> > > + select FRAME_POINTER if (!ARM_UNWIND)
> >
> >
> > So, if I understand well. If people have ARM_UNWIND but
> > FUNCTION_TRACER, it might crash at link time in case
> > they don't have a recent enough gcc version to
> > support the new -pg style?
> >
> > That doesn't look good.
> >
> > Ideally, we need HAVE_FUNCTION_TRACER to be enabled in arm
> > only if (old gcc && frame pointers) || new gcc
> >
> > And then, we need config OLD_MCOUNT:
> > old gcc && FUNCTION_TRACER
> >
> > and config NEW_MCOUNT:
> > new gcc && FUNCTION_TRACER
> >
> > so that we can selectively build mcount or __gnu_mcount_nc.
> >
> > Hmm, I fear we can't check gcc version from Kconfig, as I'm
> > grepping on Kconfig files...
>
>
> I would not check gcc version through KCONFIG, but you can have the gcc
> version checked and define another macro in a header somewhere, like
> asm/ftrace.h. Then we could do something different while it is
> compiling.


Yeah. I understand now why we can't do that on Kconfig time, HOSTCC
can be different than CC.

The most important thing is to have a message that describes the issue
if the compiler-config combination is impossible.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 0/15 V10] Work to enable SmartMedia/xD support in mtd
Next: [PATCH v2 10/12] ACPI: processor: refactor internal map_lsapic_id()