[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