From: Claudio Scordino <claudio@evidence.eu.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: rmk@arm.linux.org.uk, linux-kernel@vger.kernel.org,
kernel@arm.linux.org.uk
Subject: [PATCH] Default setting of the ARM_UNWIND option
Date: Mon, 19 Oct 2009 12:16:50 +0200 [thread overview]
Message-ID: <4ADC3C92.3000709@evidence.eu.com> (raw)
In-Reply-To: <1255620333.10164.77.camel@pc1117.cambridge.arm.com>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
[email cut-and-pasted from a private discussion...]
>> moving from release 2.6.27 to release 2.6.32-rc4, my ARM board
>> (derived from AT91SAM9623-EK) started hanging at the initial
>> "Calibrating delay loop" message.
>>
>> After some inspection, I found out the problem to be with commit
>> adf8b37bafc1495393201a2ae4235846371870d0.
>>
>> In practice, it enables stack unwinding support by default. However, if
>> enabled, it hangs my machine.
>>
>> The problem might be with my compiler (according to the help, stack
>> unwinding only works with EABI compilers).
>>
>> I'm using a CodeSourcery gcc 4.2.1 "arm-none-linux-gnueabi".
>>
>
> I think 4.2.1 generates really buggy code with -fno-frame-pointer,
> nothing to do with the stack unwinding implementation in the kernel. I
> would recommend you either use a newer compiler or disables ARM_UNWIND
> in your .config (which automatically re-enables FRAMEPOINTER).
>
Hi Catalin,
thank you for your answer.
In my opinion, we should change the default setting of this option.
Having "yes" as default policy for ARM_UNWIND means that, by default,
the kernel does not boot if a user has a buggy compiler (like me) and
he/she doesn't explicitly disable the ARM_UNWIND option.
Consider that people may not know that their problem is related to the
ARM_UNWIND option. Therefore, they may waste time just bisecting to
understand where their problem really is.
Therefore, my suggestion is to change the default policy of this option
as shown in the attached patch, to avoid a potential waste of time of
developers. Users who know that they can enable this option, will enable
it.
Let me know what you think about this suggestion.
Many thanks and my best regards,
Claudio
[-- Attachment #2: 0001-Disable-stack-unwinding-support-by-default-since-it.patch --]
[-- Type: text/x-patch, Size: 1203 bytes --]
From: Claudio Scordino <claudio@evidence.eu.com>
Date: Mon, 19 Oct 2009 11:59:16 +0200
Subject: [PATCH 1/1] Disable stack unwinding support by default, since it does not work on some buggy or not-EABI compilers.
Disable stack unwinding support by default, since it does not work on some
buggy or not-EABI compilers.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
---
arch/arm/Kconfig.debug | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 1a6f70e..925e3fd 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -19,13 +19,13 @@ config FRAME_POINTER
config ARM_UNWIND
bool "Enable stack unwinding support"
depends on AEABI && EXPERIMENTAL
- default y
+ default n
help
This option enables stack unwinding support in the kernel
using the information automatically generated by the
compiler. The resulting kernel image is slightly bigger but
the performance is not affected. Currently, this feature
- only works with EABI compilers. If unsure say Y.
+ only works with EABI compilers. If unsure say N.
config DEBUG_USER
bool "Verbose user fault messages"
--
1.6.0.4
next prev parent reply other threads:[~2009-10-19 10:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4AD73DA4.4050006@evidence.eu.com>
[not found] ` <1255620333.10164.77.camel@pc1117.cambridge.arm.com>
2009-10-19 10:15 ` [PATCH] Default setting of the ARM_UNWIND option Claudio Scordino
2009-10-19 10:16 ` Claudio Scordino [this message]
2009-10-26 8:27 ` [PATCH][RE-SUBMIT] " Claudio Scordino
2009-10-26 11:10 ` Catalin Marinas
2009-10-28 11:37 ` Claudio Scordino
2009-10-28 11:37 ` Claudio Scordino
2009-10-28 14:58 ` Catalin Marinas
2009-10-30 11:11 ` Claudio Scordino
2009-10-30 12:39 ` Catalin Marinas
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=4ADC3C92.3000709@evidence.eu.com \
--to=claudio@evidence.eu.com \
--cc=catalin.marinas@arm.com \
--cc=kernel@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).