On Mon, May 18, 2009 at 10:13:55AM -0700, Kevin Hilman wrote: > Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes: > > > On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote: > >> Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes: > >> > >> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: > >> >> "stanley.miao" <stanley.miao@xxxxxxxxxxxxx> 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/linux-omap@xxxxxxxxxxxxxxx/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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
