On Mon, May 18, 2009 at 10:13:55AM -0700, Kevin Hilman wrote:
> Russell King - ARM Linux <[email protected]> writes:
>
> > On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote:
> >> Russell King - ARM Linux <[email protected]> writes:
> >>
> >> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote:
> >> >> "stanley.miao" <[email protected]> writes:
> >> >>
> >> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been
> >> >> >> reported earlier. Switching to 2008q3 works.
> >> >> >
> >> >> > Yeah, Now the kernel booted. it's compiler's problem.
> >> >>
> >> >> I was bitten by the same problem few weeks ago. Any chance of getting a
> >> >> warning/error if using 2007q3 compiler until the problem is fixed?
> >> >
> >> > Is there any way of detecting the 2007q3 compiler?
> >> >
> >> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and
> >> > __GNUC_PATCHLEVEL__ to identify the three digit version number.
> >>
> >> I don't know, most probably not. But Jon Hunter investigated the issue
> >> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS:
> >>
> >> http://www.mail-archive.com/[email protected]/msg12403.html
> >>
> >> So maybe we can fix or workaround this.
> >
> > Why does this change anything? FRAME_POINTERS seems to be enabled
> > anyway (and should be given the Kconfig setup we have.)
>
> See the 'depends on' line in lib/Kconfig.debug. The result is that
> without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y
> in your .config, it gets dropped if the arch doesn't set
> CONFIG_ARCH_WANT_FRAME_POINTERS.
Well, two things.
1. We don't want to force frame pointers on if unwinding support is enabled.
2. The lib/Kconfig.debug entry is overridden by ARM's own version in
arch/arm/Kconfig.debug. I've added samr into the discussion since
he created this.
arch/arm/Kconfig.debug:
# RMK wants arm kernels compiled with frame pointers or stack unwinding.
# If you know what you are doing and are willing to live without stack
# traces, you can get a slightly smaller kernel by setting this option to
# n, but then RMK will have to kill you ;).
config FRAME_POINTER
bool
default y if !ARM_UNWIND
help
If you say N here, the resulting kernel will be slightly smaller and
faster. However, if neither FRAME_POINTER nor ARM_UNWIND are enabled,
when a problem occurs with the kernel, the information that is
reported is severely limited.
And lib/Kconfig.debug:
config FRAME_POINTER
bool "Compile the kernel with frame pointers"
depends on DEBUG_KERNEL && \
(CRIS || M68K || M68KNOMMU || FRV || UML || \
AVR32 || SUPERH || BLACKFIN || MN10300) || \
ARCH_WANT_FRAME_POINTERS
default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
help
If you say Y here the resulting kernel image will be slightly
larger and slower, but it gives very useful debugging information
in case of kernel bugs. (precise oopses/stacktraces/warnings)
this still results in frame pointers being enabled. This is because the
ARM version follows the one in lib/, it overrides it rather than
supplementing the generic version. I've just checked that by adding
'n &&' to that depends on line in lib/Kconfig.debug, and making oldconfig.
I still end up with FRAME_POINTER=y in my configs. However, if I stub out
the 'default y' line in arch/arm/Kconfig.debug, it goes away.
So I think setting ARCH_WANT_FRAME_POINTERS will be ineffectual.
Moreover, I don't think forcing frame pointers to be enabled even with
unwinding support is the right solution - if we have frame pointers
there's no need for unwind support (so maybe the right answer is to
force unwind support off for the time being?)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
