linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:15:29 +0200	[thread overview]
Message-ID: <4ADC3C41.7000207@evidence.eu.com> (raw)
In-Reply-To: <1255620333.10164.77.camel@pc1117.cambridge.arm.com>

[-- Attachment #1: Type: text/plain, Size: 1766 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: 1171 bytes --]

>From 3b688dbebb5fb3345e48cd491eb387434db165da Mon Sep 17 00:00:00 2001
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.


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


       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   ` Claudio Scordino [this message]
2009-10-19 10:16   ` [PATCH] Default setting of the ARM_UNWIND option Claudio Scordino
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=4ADC3C41.7000207@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).