Discussing the Linux ARM kernel

Catalin Marinas | 23 May 2011 13:16

[PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Newer versions of gcc generate unaligned accesses by default, causing
kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
-mno-unaligned-access option to gcc.

Reported-by: Ali Saidi <ali.saidi <at> arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas <at> arm.com>
---
 arch/arm/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index c7d321a..1c383d0 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
 <at>  <at>  -101,6 +101,10  <at>  <at>  ifeq ($(CONFIG_ARM_UNWIND),y)
 CFLAGS_ABI	+=-funwind-tables
 endif

+ifeq ($(CONFIG_ALIGNMENT_TRAP),y)
+CFLAGS_ABI	+=$(call cc-option,-mno-unaligned-access,)
+endif
+
 ifeq ($(CONFIG_THUMB2_KERNEL),y)
 AFLAGS_AUTOIT	:=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
 AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)

headers

Måns Rullgård | 23 May 2011 14:30

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Catalin Marinas <catalin.marinas <at> arm.com> writes:

> Newer versions of gcc generate unaligned accesses by default, causing
> kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> -mno-unaligned-access option to gcc.

Wouldn't it make more sense to disable strict alignment checking in
kernel mode regardless of this option.  I can't imagine why it would
ever be desirable.  IMO the usermode default should also be changed to
allow unaligned accesses on ARMv6 and up.

I don't mind this patch as such, but I would not consider it a correct
solution.

--

-- 
Måns Rullgård
mans <at> mansr.com

headers

Russell King - ARM Linux | 23 May 2011 15:25

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Mon, May 23, 2011 at 01:30:43PM +0100, Måns Rullgård wrote:
> Catalin Marinas <catalin.marinas <at> arm.com> writes:
> 
> > Newer versions of gcc generate unaligned accesses by default, causing
> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> > -mno-unaligned-access option to gcc.
> 
> Wouldn't it make more sense to disable strict alignment checking in
> kernel mode regardless of this option.  I can't imagine why it would
> ever be desirable.  IMO the usermode default should also be changed to
> allow unaligned accesses on ARMv6 and up.

We do disable strict alignment checking but only at alignment fault
handler init time:

        /*
         * ARMv6 and later CPUs can perform unaligned accesses for
         * most single load and store instructions up to word size.
         * LDM, STM, LDRD and STRD still need to be handled.
         *
         * Ignoring the alignment fault is not an option on these
         * CPUs since we spin re-faulting the instruction without
         * making any progress.
         */
        if (cpu_architecture() >= CPU_ARCH_ARMv6 && (cr_alignment & CR_U)) {
                cr_alignment &= ~CR_A;
                cr_no_alignment &= ~CR_A;
                set_cr(cr_alignment);
                ai_usermode = UM_FIXUP;
        }

(Continue reading)

headers

Russell King - ARM Linux | 23 May 2011 15:21

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
> Newer versions of gcc generate unaligned accesses by default, causing
> kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> -mno-unaligned-access option to gcc.

This description doesn't make sense.  If we have alignment traps enabled,
then we _expect_ to fix up unaligned loads and stores.

Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.

So what's the _actual_ problem that this is trying to address?  What's
the panic/oops look like?  And that information should be in the commit
description _anyway_.

headers

Catalin Marinas | 23 May 2011 15:51

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
> > Newer versions of gcc generate unaligned accesses by default, causing
> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> > -mno-unaligned-access option to gcc.
> 
> This description doesn't make sense.  If we have alignment traps enabled,
> then we _expect_ to fix up unaligned loads and stores.
> 
> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
> 
> So what's the _actual_ problem that this is trying to address?  What's
> the panic/oops look like?  And that information should be in the commit
> description _anyway_.

OK, not clear from my commit log. See below for details (I'll add them
to the log):

http://www.codesourcery.com/archives/arm-gnu/msg04202.html

Basically the fault happens before we call alignment_init(). There are
other ways to fix this issue (like initialising the alignment handler
earlier).

--

-- 
Catalin

headers

Måns Rullgård | 23 May 2011 16:37

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Catalin Marinas <catalin.marinas <at> arm.com> writes:

> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
>> > Newer versions of gcc generate unaligned accesses by default, causing
>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
>> > -mno-unaligned-access option to gcc.
>> 
>> This description doesn't make sense.  If we have alignment traps enabled,
>> then we _expect_ to fix up unaligned loads and stores.
>> 
>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
>> 
>> So what's the _actual_ problem that this is trying to address?  What's
>> the panic/oops look like?  And that information should be in the commit
>> description _anyway_.
>
> OK, not clear from my commit log. See below for details (I'll add them
> to the log):
>
> http://www.codesourcery.com/archives/arm-gnu/msg04202.html
>
> Basically the fault happens before we call alignment_init(). There are
> other ways to fix this issue (like initialising the alignment handler
> earlier).

The reset value of SCTLR.A is 0 on ARMv7.  Something must be setting it
to 1 early, before the alignment trap handler is initialised.  This
something is what needs to be changed.

(Continue reading)

headers

Catalin Marinas | 23 May 2011 16:41

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

2011/5/23 Måns Rullgård <mans <at> mansr.com>:
> Catalin Marinas <catalin.marinas <at> arm.com> writes:
>
>> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
>>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
>>> > Newer versions of gcc generate unaligned accesses by default, causing
>>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
>>> > -mno-unaligned-access option to gcc.
>>>
>>> This description doesn't make sense.  If we have alignment traps enabled,
>>> then we _expect_ to fix up unaligned loads and stores.
>>>
>>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
>>>
>>> So what's the _actual_ problem that this is trying to address?  What's
>>> the panic/oops look like?  And that information should be in the commit
>>> description _anyway_.
>>
>> OK, not clear from my commit log. See below for details (I'll add them
>> to the log):
>>
>> http://www.codesourcery.com/archives/arm-gnu/msg04202.html
>>
>> Basically the fault happens before we call alignment_init(). There are
>> other ways to fix this issue (like initialising the alignment handler
>> earlier).
>
> The reset value of SCTLR.A is 0 on ARMv7.  Something must be setting it
> to 1 early, before the alignment trap handler is initialised.  This
> something is what needs to be changed.

(Continue reading)

headers

Russell King - ARM Linux | 23 May 2011 16:52

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Mon, May 23, 2011 at 03:37:49PM +0100, Måns Rullgård wrote:
> Catalin Marinas <catalin.marinas <at> arm.com> writes:
> 
> > On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
> >> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
> >> > Newer versions of gcc generate unaligned accesses by default, causing
> >> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> >> > -mno-unaligned-access option to gcc.
> >> 
> >> This description doesn't make sense.  If we have alignment traps enabled,
> >> then we _expect_ to fix up unaligned loads and stores.
> >> 
> >> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
> >> 
> >> So what's the _actual_ problem that this is trying to address?  What's
> >> the panic/oops look like?  And that information should be in the commit
> >> description _anyway_.
> >
> > OK, not clear from my commit log. See below for details (I'll add them
> > to the log):
> >
> > http://www.codesourcery.com/archives/arm-gnu/msg04202.html
> >
> > Basically the fault happens before we call alignment_init(). There are
> > other ways to fix this issue (like initialising the alignment handler
> > earlier).
> 
> The reset value of SCTLR.A is 0 on ARMv7.  Something must be setting it
> to 1 early, before the alignment trap handler is initialised.  This
> something is what needs to be changed.

(Continue reading)

headers

Catalin Marinas | 24 May 2011 11:39

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
> > Newer versions of gcc generate unaligned accesses by default, causing
> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> > -mno-unaligned-access option to gcc.
> 
> This description doesn't make sense.  If we have alignment traps enabled,
> then we _expect_ to fix up unaligned loads and stores.
> 
> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
> 
> So what's the _actual_ problem that this is trying to address?  What's
> the panic/oops look like?  And that information should be in the commit
> description _anyway_.

Does the patch below look better?

We cannot move alignment_init() earlier as we don't know how early the
compiler would generate unaligned accesses. An alternative is some
#ifdef's in head.S. Please let me know which variant you prefer.

ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

From: Catalin Marinas <catalin.marinas <at> arm.com>

Newer versions of gcc generate unaligned accesses by default. For ARMv6
and newer architecture versions, Linux disables the alignment trapping
(SCTLR.A) in the alignment_init() function. However, unaligned accesses
may still happen before this function is called (currently
pcpu_dump_alloc_info causes a kernel panic).

(Continue reading)

headers

Måns Rullgård | 24 May 2011 16:17

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Catalin Marinas <catalin.marinas <at> arm.com> writes:

> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
>> > Newer versions of gcc generate unaligned accesses by default, causing
>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
>> > -mno-unaligned-access option to gcc.
>> 
>> This description doesn't make sense.  If we have alignment traps enabled,
>> then we _expect_ to fix up unaligned loads and stores.
>> 
>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
>> 
>> So what's the _actual_ problem that this is trying to address?  What's
>> the panic/oops look like?  And that information should be in the commit
>> description _anyway_.
>
> Does the patch below look better?
>
> We cannot move alignment_init() earlier as we don't know how early the
> compiler would generate unaligned accesses. An alternative is some
> #ifdef's in head.S. Please let me know which variant you prefer.

ifdefs may be ugly, but I don't see a better solution here.  Crippling
the entire build to make a couple of lines slightly more aesthetically
pleasing doesn't seem right to me.

--

-- 
Måns Rullgård
mans <at> mansr.com

(Continue reading)

headers

Catalin Marinas | 24 May 2011 17:26

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

2011/5/24 Måns Rullgård <mans <at> mansr.com>:
> Catalin Marinas <catalin.marinas <at> arm.com> writes:
>
>> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
>>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
>>> > Newer versions of gcc generate unaligned accesses by default, causing
>>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
>>> > -mno-unaligned-access option to gcc.
>>>
>>> This description doesn't make sense.  If we have alignment traps enabled,
>>> then we _expect_ to fix up unaligned loads and stores.
>>>
>>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
>>>
>>> So what's the _actual_ problem that this is trying to address?  What's
>>> the panic/oops look like?  And that information should be in the commit
>>> description _anyway_.
>>
>> Does the patch below look better?
>>
>> We cannot move alignment_init() earlier as we don't know how early the
>> compiler would generate unaligned accesses. An alternative is some
>> #ifdef's in head.S. Please let me know which variant you prefer.
>
> ifdefs may be ugly, but I don't see a better solution here.  Crippling
> the entire build to make a couple of lines slightly more aesthetically
> pleasing doesn't seem right to me.

BTW, are we sure that the code generated with unaligned accesses is
better? AFAIK, while processors support unaligned accesses, they may

(Continue reading)

headers

Måns Rullgård | 24 May 2011 18:23

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Catalin Marinas <catalin.marinas <at> arm.com> writes:

> 2011/5/24 Måns Rullgård <mans <at> mansr.com>:
>> Catalin Marinas <catalin.marinas <at> arm.com> writes:
>>
>>> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
>>>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
>>>> > Newer versions of gcc generate unaligned accesses by default, causing
>>>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
>>>> > -mno-unaligned-access option to gcc.
>>>>
>>>> This description doesn't make sense.  If we have alignment traps enabled,
>>>> then we _expect_ to fix up unaligned loads and stores.
>>>>
>>>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
>>>>
>>>> So what's the _actual_ problem that this is trying to address?  What's
>>>> the panic/oops look like?  And that information should be in the commit
>>>> description _anyway_.
>>>
>>> Does the patch below look better?
>>>
>>> We cannot move alignment_init() earlier as we don't know how early the
>>> compiler would generate unaligned accesses. An alternative is some
>>> #ifdef's in head.S. Please let me know which variant you prefer.
>>
>> ifdefs may be ugly, but I don't see a better solution here.  Crippling
>> the entire build to make a couple of lines slightly more aesthetically
>> pleasing doesn't seem right to me.
>

(Continue reading)

headers

Nicolas Pitre | 24 May 2011 19:26

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Tue, 24 May 2011, Måns Rullgård wrote:

> Catalin Marinas <catalin.marinas <at> arm.com> writes:
> 
> > 2011/5/24 Måns Rullgård <mans <at> mansr.com>:
> >> Catalin Marinas <catalin.marinas <at> arm.com> writes:
> >>
> >>> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
> >>>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
> >>>> > Newer versions of gcc generate unaligned accesses by default, causing
> >>>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> >>>> > -mno-unaligned-access option to gcc.
> >>>>
> >>>> This description doesn't make sense.  If we have alignment traps enabled,
> >>>> then we _expect_ to fix up unaligned loads and stores.
> >>>>
> >>>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
> >>>>
> >>>> So what's the _actual_ problem that this is trying to address?  What's
> >>>> the panic/oops look like?  And that information should be in the commit
> >>>> description _anyway_.
> >>>
> >>> Does the patch below look better?
> >>>
> >>> We cannot move alignment_init() earlier as we don't know how early the
> >>> compiler would generate unaligned accesses. An alternative is some
> >>> #ifdef's in head.S. Please let me know which variant you prefer.
> >>
> >> ifdefs may be ugly, but I don't see a better solution here.  Crippling
> >> the entire build to make a couple of lines slightly more aesthetically

(Continue reading)

headers

Dave Martin | 24 May 2011 19:13

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
> 2011/5/24 Måns Rullgård <mans <at> mansr.com>:
> > Catalin Marinas <catalin.marinas <at> arm.com> writes:
> >
> >> On Mon, 2011-05-23 at 14:21 +0100, Russell King - ARM Linux wrote:
> >>> On Mon, May 23, 2011 at 12:16:48PM +0100, Catalin Marinas wrote:
> >>> > Newer versions of gcc generate unaligned accesses by default, causing
> >>> > kernel panics when CONFIG_ALIGNMENT_TRAP is enabled. This patch adds the
> >>> > -mno-unaligned-access option to gcc.
> >>>
> >>> This description doesn't make sense.  If we have alignment traps enabled,
> >>> then we _expect_ to fix up unaligned loads and stores.
> >>>
> >>> Therefore there should be no panic if CONFIG_ALIGNMENT_TRAP is enabled.
> >>>
> >>> So what's the _actual_ problem that this is trying to address?  What's
> >>> the panic/oops look like?  And that information should be in the commit
> >>> description _anyway_.
> >>
> >> Does the patch below look better?
> >>
> >> We cannot move alignment_init() earlier as we don't know how early the
> >> compiler would generate unaligned accesses. An alternative is some
> >> #ifdef's in head.S. Please let me know which variant you prefer.
> >
> > ifdefs may be ugly, but I don't see a better solution here.  Crippling
> > the entire build to make a couple of lines slightly more aesthetically
> > pleasing doesn't seem right to me.
> 
> BTW, are we sure that the code generated with unaligned accesses is

(Continue reading)

headers

Catalin Marinas | 25 May 2011 13:14

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
> On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
> > BTW, are we sure that the code generated with unaligned accesses is
> > better? AFAIK, while processors support unaligned accesses, they may
> > not always be optimal.
> 
> The code gcc generates to synthesise an unaligned access using aligned
> accesses is pretty simplistic:
...
> For code which natively needs to read unaligned fields from data structures,
> I sincerely doubt that the CPU will not beat the above code for efficiency...
> 
> So if there's code doing unaligned access to data structures for a good
> reason, building with unaligned access support turned on in the compiler
> seems a good idea, if that code might performance-critical for anything.

gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
function. We have a local variable like below (9 bytes):

	char empty_str[] = "--------";

and it looks like other stack accesses are unaligned:

c0082ba0 <pcpu_dump_alloc_info>:
c0082ba0:   e92d4ff0    push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
c0082ba4:   e3074118    movw    r4, #28952  ; 0x7118
c0082ba8:   e24dd04c    sub sp, sp, #76 ; 0x4c
c0082bac:   e34c402a    movt    r4, #49194  ; 0xc02a
c0082bb0:   e58d1014    str r1, [sp, #20]
c0082bb4:   e58d0020    str r0, [sp, #32]

(Continue reading)

headers

Dave Martin | 25 May 2011 14:43

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
> > > BTW, are we sure that the code generated with unaligned accesses is
> > > better? AFAIK, while processors support unaligned accesses, they may
> > > not always be optimal.
> > 
> > The code gcc generates to synthesise an unaligned access using aligned
> > accesses is pretty simplistic:
> ...
> > For code which natively needs to read unaligned fields from data structures,
> > I sincerely doubt that the CPU will not beat the above code for efficiency...
> > 
> > So if there's code doing unaligned access to data structures for a good
> > reason, building with unaligned access support turned on in the compiler
> > seems a good idea, if that code might performance-critical for anything.
> 
> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
> function. We have a local variable like below (9 bytes):
> 
> 	char empty_str[] = "--------";
> 
> and it looks like other stack accesses are unaligned:
> 
> c0082ba0 <pcpu_dump_alloc_info>:
> c0082ba0:   e92d4ff0    push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
> c0082ba4:   e3074118    movw    r4, #28952  ; 0x7118
> c0082ba8:   e24dd04c    sub sp, sp, #76 ; 0x4c
> c0082bac:   e34c402a    movt    r4, #49194  ; 0xc02a
> c0082bb0:   e58d1014    str r1, [sp, #20]

(Continue reading)

headers

Måns Rullgård | 25 May 2011 15:32

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Dave Martin <dave.martin <at> linaro.org> writes:

> On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
>> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
>> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
>> > > BTW, are we sure that the code generated with unaligned accesses is
>> > > better? AFAIK, while processors support unaligned accesses, they may
>> > > not always be optimal.
>> > 
>> > The code gcc generates to synthesise an unaligned access using aligned
>> > accesses is pretty simplistic:
>> ...
>> > For code which natively needs to read unaligned fields from data structures,
>> > I sincerely doubt that the CPU will not beat the above code for efficiency...
>> > 
>> > So if there's code doing unaligned access to data structures for a good
>> > reason, building with unaligned access support turned on in the compiler
>> > seems a good idea, if that code might performance-critical for anything.
>> 
>> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
>> function. We have a local variable like below (9 bytes):
>> 
>> 	char empty_str[] = "--------";
>> 
>> and it looks like other stack accesses are unaligned:
>> 
>> c0082ba0 <pcpu_dump_alloc_info>:
>> c0082ba0:   e92d4ff0    push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
>> c0082ba4:   e3074118    movw    r4, #28952  ; 0x7118
>> c0082ba8:   e24dd04c    sub sp, sp, #76 ; 0x4c

(Continue reading)

headers

Dave Martin | 25 May 2011 16:05

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Wed, May 25, 2011 at 02:32:13PM +0100, Måns Rullgård wrote:
> Dave Martin <dave.martin <at> linaro.org> writes:
> 
> > On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
> >> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
> >> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
> >> > > BTW, are we sure that the code generated with unaligned accesses is
> >> > > better? AFAIK, while processors support unaligned accesses, they may
> >> > > not always be optimal.
> >> > 
> >> > The code gcc generates to synthesise an unaligned access using aligned
> >> > accesses is pretty simplistic:
> >> ...
> >> > For code which natively needs to read unaligned fields from data structures,
> >> > I sincerely doubt that the CPU will not beat the above code for efficiency...
> >> > 
> >> > So if there's code doing unaligned access to data structures for a good
> >> > reason, building with unaligned access support turned on in the compiler
> >> > seems a good idea, if that code might performance-critical for anything.
> >> 
> >> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
> >> function. We have a local variable like below (9 bytes):
> >> 
> >> 	char empty_str[] = "--------";
> >> 
> >> and it looks like other stack accesses are unaligned:
> >> 
> >> c0082ba0 <pcpu_dump_alloc_info>:
> >> c0082ba0:   e92d4ff0    push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
> >> c0082ba4:   e3074118    movw    r4, #28952  ; 0x7118

(Continue reading)

headers

Måns Rullgård | 25 May 2011 16:48

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Dave Martin <dave.martin <at> linaro.org> writes:

> On Wed, May 25, 2011 at 02:32:13PM +0100, Måns Rullgård wrote:
>> Dave Martin <dave.martin <at> linaro.org> writes:
>> 
>> > On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
>> >> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
>> >> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
>> >> > > BTW, are we sure that the code generated with unaligned accesses is
>> >> > > better? AFAIK, while processors support unaligned accesses, they may
>> >> > > not always be optimal.
>> >> > 
>> >> > The code gcc generates to synthesise an unaligned access using aligned
>> >> > accesses is pretty simplistic:
>> >> ...
>> >> > For code which natively needs to read unaligned fields from data structures,
>> >> > I sincerely doubt that the CPU will not beat the above code for efficiency...
>> >> > 
>> >> > So if there's code doing unaligned access to data structures for a good
>> >> > reason, building with unaligned access support turned on in the compiler
>> >> > seems a good idea, if that code might performance-critical for anything.
>> >> 
>> >> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
>> >> function. We have a local variable like below (9 bytes):
>> >> 
>> >> 	char empty_str[] = "--------";
>> >> 
>> >> and it looks like other stack accesses are unaligned:
>> >> 
>> >> c0082ba0 <pcpu_dump_alloc_info>:

(Continue reading)

headers

Catalin Marinas | 25 May 2011 16:50

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

2011/5/25 Måns Rullgård <mans <at> mansr.com>:
> Dave Martin <dave.martin <at> linaro.org> writes:
>
>> On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
>>> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
>>> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
>>> > > BTW, are we sure that the code generated with unaligned accesses is
>>> > > better? AFAIK, while processors support unaligned accesses, they may
>>> > > not always be optimal.
>>> >
>>> > The code gcc generates to synthesise an unaligned access using aligned
>>> > accesses is pretty simplistic:
>>> ...
>>> > For code which natively needs to read unaligned fields from data structures,
>>> > I sincerely doubt that the CPU will not beat the above code for efficiency...
>>> >
>>> > So if there's code doing unaligned access to data structures for a good
>>> > reason, building with unaligned access support turned on in the compiler
>>> > seems a good idea, if that code might performance-critical for anything.
>>>
>>> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
>>> function. We have a local variable like below (9 bytes):
>>>
>>>      char empty_str[] = "--------";
>>>
>>> and it looks like other stack accesses are unaligned:
>>>
>>> c0082ba0 <pcpu_dump_alloc_info>:
>>> c0082ba0:   e92d4ff0    push    {r4, r5, r6, r7, r8, r9, sl, fp, lr}
>>> c0082ba4:   e3074118    movw    r4, #28952  ; 0x7118

(Continue reading)

headers

Måns Rullgård | 25 May 2011 16:53

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Catalin Marinas <catalin.marinas <at> arm.com> writes:

> 2011/5/25 Måns Rullgård <mans <at> mansr.com>:
>> Dave Martin <dave.martin <at> linaro.org> writes:
>>
>>> On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
>>>> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
>>>> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
>>>> > > BTW, are we sure that the code generated with unaligned accesses is
>>>> > > better? AFAIK, while processors support unaligned accesses, they may
>>>> > > not always be optimal.
>>>> >
>>>> > The code gcc generates to synthesise an unaligned access using aligned
>>>> > accesses is pretty simplistic:
>>>> ...
>>>> > For code which natively needs to read unaligned fields from data structures,
>>>> > I sincerely doubt that the CPU will not beat the above code for efficiency...
>>>> >
>>>> > So if there's code doing unaligned access to data structures for a good
>>>> > reason, building with unaligned access support turned on in the compiler
>>>> > seems a good idea, if that code might performance-critical for anything.
>>>>
>>>> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
>>>> function. We have a local variable like below (9 bytes):
>>>>
>>>>      char empty_str[] = "--------";
>>>>
>>>> and it looks like other stack accesses are unaligned:
>>>>
>>>> c0082ba0 <pcpu_dump_alloc_info>:

(Continue reading)

headers

Will Deacon | 26 May 2011 19:10

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Right... [adding bunch of people to CC],

On Wed, 2011-05-25 at 15:50 +0100, Catalin Marinas wrote:
> 2011/5/25 Måns Rullgård <mans <at> mansr.com>:
> > Dave Martin <dave.martin <at> linaro.org> writes:
> >
> >> On Wed, May 25, 2011 at 12:14:08PM +0100, Catalin Marinas wrote:
> >>> On Tue, May 24, 2011 at 06:13:31PM +0100, Dave Martin wrote:
> >>> > On Tue, May 24, 2011 at 04:26:35PM +0100, Catalin Marinas wrote:
> >>> > > BTW, are we sure that the code generated with unaligned accesses is
> >>> > > better? AFAIK, while processors support unaligned accesses, they may
> >>> > > not always be optimal.
> >>> >
> >>> > The code gcc generates to synthesise an unaligned access using aligned
> >>> > accesses is pretty simplistic:
> >>> ...
> >>> > For code which natively needs to read unaligned fields from data structures,
> >>> > I sincerely doubt that the CPU will not beat the above code for efficiency...
> >>> >
> >>> > So if there's code doing unaligned access to data structures for a good
> >>> > reason, building with unaligned access support turned on in the compiler
> >>> > seems a good idea, if that code might performance-critical for anything.
> >>>
> >>> gcc generates unaligned accesses in the the pcpu_dump_alloc_info()
> >>> function. We have a local variable like below (9 bytes):
> >>>
> >>>      char empty_str[] = "--------";
> >>>
> >>> and it looks like other stack accesses are unaligned:
> >>>

(Continue reading)

headers

Måns Rullgård | 26 May 2011 20:14

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Will Deacon <will.deacon <at> arm.com> writes:

> This issue seems to be caused by passing -fconserve-stack to GCC. This
> was added in 8f7f5c9f ("kbuild: set -fconserve-stack option for gcc
> 4.5") and as you can see from the archive:
>
> http://lkml.org/lkml/2009/9/20/39
>
> it was thought to only have an impact on inlining decisions. Looking at
> the documentation for GCC 4.6:
>
> -fconserve-stack
>           Attempt to minimize stack usage. The compiler will attempt to
> use less stack space, even if that makes the program slower. This option
> implies setting the ‘large-stack-frame’ parameter to 100 and the
> ‘large-stack-frame-growth’ parameter to 400.
>
> So it sounds like we might not want to enable this blindly across all
> architectures. Indeed, on ARM, it encourages the compiler to pack
> variables on the stack which leads to the weird and wonderful alignment
> situation that has been encountered in this thread.
>
> Can we remove -fconserve-stack from the top-level Makefile (or at least
> make it conditional by architecture)?

Sounds like a good idea to me.

--

-- 
Måns Rullgård
mans <at> mansr.com

(Continue reading)

headers

Andi Kleen | 26 May 2011 21:58

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP


> So it sounds like we might not want to enable this blindly across all
> architectures. Indeed, on ARM, it encourages the compiler to pack
> variables on the stack which leads to the weird and wonderful alignment
> situation that has been encountered in this thread.

Interesting. I'm pretty sure it didn't do that when I added the flag.

Anyways making it a CONFIG is fine for me. Just don't set it on ARM. It 
should be set on x86
at least.

-Andi

headers

Nicolas Pitre | 26 May 2011 23:03

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Thu, 26 May 2011, Will Deacon wrote:

> This issue seems to be caused by passing -fconserve-stack to GCC. This
> was added in 8f7f5c9f ("kbuild: set -fconserve-stack option for gcc
> 4.5") and as you can see from the archive:
> 
> http://lkml.org/lkml/2009/9/20/39
> 
> it was thought to only have an impact on inlining decisions. Looking at
> the documentation for GCC 4.6:
> 
> -fconserve-stack
>           Attempt to minimize stack usage. The compiler will attempt to
> use less stack space, even if that makes the program slower. This option
> implies setting the ‘large-stack-frame’ parameter to 100 and the
> ‘large-stack-frame-growth’ parameter to 400.
> 
> So it sounds like we might not want to enable this blindly across all
> architectures. Indeed, on ARM, it encourages the compiler to pack
> variables on the stack which leads to the weird and wonderful alignment
> situation that has been encountered in this thread.
> 
> Can we remove -fconserve-stack from the top-level Makefile (or at least
> make it conditional by architecture)?

I think this is an orthogonal issue.

My opinion is that we should use -mno-unaligned-access by default on 
ARM.  The reason is that we've been expecting the compiler not to cause 
unaligned accesses for ages, and letting the compiler, for whatever

(Continue reading)

headers

Andi Kleen | 26 May 2011 23:10

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP


> It is possible that -fconserve-stack is still valuable on ARM given that
> it is also used with -mno-unaligned-access for other things than
> structure packing on the stack, and therefore its merits can be debated
> independently from the alignment issue at hand.

The big advantage of -fconserve-stack is that it throttles the inliner 
if the inlining
would cause too much stack growth. This is something you likely want
on ARM too, especially as code gets more and more complex.

-Andi

headers

Måns Rullgård | 26 May 2011 23:26

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Andi Kleen <ak <at> linux.intel.com> writes:

>> It is possible that -fconserve-stack is still valuable on ARM given that
>> it is also used with -mno-unaligned-access for other things than
>> structure packing on the stack, and therefore its merits can be debated
>> independently from the alignment issue at hand.
>
> The big advantage of -fconserve-stack is that it throttles the inliner
> if the inlining would cause too much stack growth. This is something
> you likely want on ARM too, especially as code gets more and more
> complex.

Is there no way to get that effect without also activating the
aggressive packing?

--

-- 
Måns Rullgård
mans <at> mansr.com

headers

Will Deacon | 27 May 2011 12:05

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Hi Andi,

On Thu, 2011-05-26 at 22:10 +0100, Andi Kleen wrote:
> 
> > It is possible that -fconserve-stack is still valuable on ARM given that
> > it is also used with -mno-unaligned-access for other things than
> > structure packing on the stack, and therefore its merits can be debated
> > independently from the alignment issue at hand.
> 
> The big advantage of -fconserve-stack is that it throttles the inliner
> if the inlining
> would cause too much stack growth. This is something you likely want
> on ARM too, especially as code gets more and more complex.

Do you have any concrete examples of -fconserve-stack giving an overall
win that isn't in the noise? The fact that the GCC documentation
explicitly states that enabling the option can lead to `making the
program slower' does make me question why we're enabling it in the first
place.

>From private conversation, the GCC guys don't seem to think this is a
bug so I'm reluctant to open a bugzilla ticket.

Will

headers

Andi Kleen | 27 May 2011 18:53

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP


> Do you have any concrete examples of -fconserve-stack giving an overall
> win that isn't in the noise? The fact that the GCC documentation
> explicitly states that enabling the option can lead to `making the
> program slower' does make me question why we're enabling it in the first
> place.

Because the kernel has a limited stack. We had a few cases in the past where
inlining blew it, especially in large ioctl switch() functions which inlined
lots of others.

On modern gccs it's better because it is smarter about sharing stack 
slots in large
functions. This was also worked around with manual noinlines.

But it's still far safer to tell gcc to conserve stack.

I consider the ARM gcc behaviour just a bug. The thing was really only 
intended
for the inliner (I asked for it originally)

-Andi

headers

Russell King - ARM Linux | 26 May 2011 23:51

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Thu, May 26, 2011 at 05:03:39PM -0400, Nicolas Pitre wrote:
> It is possible that -fconserve-stack is still valuable on ARM given that 
> it is also used with -mno-unaligned-access for other things than 
> structure packing on the stack, and therefore its merits can be debated 
> independently from the alignment issue at hand.

Catalin said in his mail "I haven't tried with -mno-unaligned-access, I
suspect the variables on the stack would be aligned.".  So I don't think
we know enough to say whether -mno-unaligned-access avoids the stack
packing.

headers

Andi Kleen | 27 May 2011 00:29

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP


> Catalin said in his mail "I haven't tried with -mno-unaligned-access, I
> suspect the variables on the stack would be aligned.".  So I don't think
> we know enough to say whether -mno-unaligned-access avoids the stack
> packing.

It won't, the arm gcc code just checks flag_conserve_stack.
IMHO it's just a gcc bug. You should report it to 
http://gcc.gnu.org/bugzilla

As a temporary workaround you can disable it in the kernel too, but as soon
as the compiler it's fixed I would recommend considering to reenable it.

-Andi

headers

Catalin Marinas | 27 May 2011 10:38

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Thu, May 26, 2011 at 10:51:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 26, 2011 at 05:03:39PM -0400, Nicolas Pitre wrote:
> > It is possible that -fconserve-stack is still valuable on ARM given that
> > it is also used with -mno-unaligned-access for other things than
> > structure packing on the stack, and therefore its merits can be debated
> > independently from the alignment issue at hand.
> 
> Catalin said in his mail "I haven't tried with -mno-unaligned-access, I
> suspect the variables on the stack would be aligned.".  So I don't think
> we know enough to say whether -mno-unaligned-access avoids the stack
> packing.

OK, I tried this now:

-fconserve-stack: we get unaligned accesses on the stack because the
newer versions of gcc turned unaligned accesses on by default.

-fconserve-stack -mno-unaligned-access: the stack variables are aligned.
We probably get the benefit of -fconserve-stack as well.

So as per the initial post in this thread, we could have
-mno-unaligned-access on ARM always on (when CONFIG_ALIGNMENT_TRAP). As
Nicolas suggested, we could compile some files with -munaligned-access
(and maybe -fno-conserve-stack).

I raised this with the gcc guys so they are looking into it. But it
really doesn't look like a gcc bug as long as -mno-unaligned-access is
taken into account.

--

--

(Continue reading)

headers

Russell King - ARM Linux | 27 May 2011 10:54

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Fri, May 27, 2011 at 09:38:08AM +0100, Catalin Marinas wrote:
> OK, I tried this now:
> 
> -fconserve-stack: we get unaligned accesses on the stack because the
> newer versions of gcc turned unaligned accesses on by default.
> 
> -fconserve-stack -mno-unaligned-access: the stack variables are aligned.
> We probably get the benefit of -fconserve-stack as well.
> 
> So as per the initial post in this thread, we could have
> -mno-unaligned-access on ARM always on (when CONFIG_ALIGNMENT_TRAP). As
> Nicolas suggested, we could compile some files with -munaligned-access
> (and maybe -fno-conserve-stack).
> 
> I raised this with the gcc guys so they are looking into it. But it
> really doesn't look like a gcc bug as long as -mno-unaligned-access is
> taken into account.

Ok, we need to check one last thing, and that's what the behaviour is
with -mno-unaligned-access and packed structures (such as the ethernet
header).  If it makes no difference, then I suggest we always build
with -mno-unaligned-access.

headers

Catalin Marinas | 27 May 2011 11:51

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Fri, May 27, 2011 at 09:54:14AM +0100, Russell King - ARM Linux wrote:
> On Fri, May 27, 2011 at 09:38:08AM +0100, Catalin Marinas wrote:
> > OK, I tried this now:
> >
> > -fconserve-stack: we get unaligned accesses on the stack because the
> > newer versions of gcc turned unaligned accesses on by default.
> >
> > -fconserve-stack -mno-unaligned-access: the stack variables are aligned.
> > We probably get the benefit of -fconserve-stack as well.
> >
> > So as per the initial post in this thread, we could have
> > -mno-unaligned-access on ARM always on (when CONFIG_ALIGNMENT_TRAP). As
> > Nicolas suggested, we could compile some files with -munaligned-access
> > (and maybe -fno-conserve-stack).
> >
> > I raised this with the gcc guys so they are looking into it. But it
> > really doesn't look like a gcc bug as long as -mno-unaligned-access is
> > taken into account.
> 
> Ok, we need to check one last thing, and that's what the behaviour is
> with -mno-unaligned-access and packed structures (such as the ethernet
> header).  If it makes no difference, then I suggest we always build
> with -mno-unaligned-access.

I tried some simple code below:

struct test {
	unsigned char a[6];
	unsigned long b;
} __attribute__((packed));

(Continue reading)

headers

Catalin Marinas | 27 May 2011 11:56

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

On Fri, 2011-05-27 at 10:51 +0100, Catalin Marinas wrote:
> On Fri, May 27, 2011 at 09:54:14AM +0100, Russell King - ARM Linux wrote:
> > On Fri, May 27, 2011 at 09:38:08AM +0100, Catalin Marinas wrote:
> > > OK, I tried this now:
> > >
> > > -fconserve-stack: we get unaligned accesses on the stack because the
> > > newer versions of gcc turned unaligned accesses on by default.
> > >
> > > -fconserve-stack -mno-unaligned-access: the stack variables are aligned.
> > > We probably get the benefit of -fconserve-stack as well.
> > >
> > > So as per the initial post in this thread, we could have
> > > -mno-unaligned-access on ARM always on (when CONFIG_ALIGNMENT_TRAP). As
> > > Nicolas suggested, we could compile some files with -munaligned-access
> > > (and maybe -fno-conserve-stack).
> > >
> > > I raised this with the gcc guys so they are looking into it. But it
> > > really doesn't look like a gcc bug as long as -mno-unaligned-access is
> > > taken into account.
> > 
> > Ok, we need to check one last thing, and that's what the behaviour is
> > with -mno-unaligned-access and packed structures (such as the ethernet
> > header).  If it makes no difference, then I suggest we always build
> > with -mno-unaligned-access.
> 
> I tried some simple code below:
> 
> struct test {
> 	unsigned char a[6];
> 	unsigned long b;

(Continue reading)

headers

Måns Rullgård | 27 May 2011 14:46

Re: [PATCH] ARM: Do not allow unaligned accesses when CONFIG_ALIGNMENT_TRAP

Catalin Marinas <catalin.marinas <at> arm.com> writes:

> On Fri, May 27, 2011 at 09:54:14AM +0100, Russell King - ARM Linux wrote:
>> 
>> Ok, we need to check one last thing, and that's what the behaviour is
>> with -mno-unaligned-access and packed structures (such as the ethernet
>> header).  If it makes no difference, then I suggest we always build
>> with -mno-unaligned-access.
>
> I tried some simple code below:
>
> struct test {
> 	unsigned char a[6];
> 	unsigned long b;
> } __attribute__((packed));
>
> void set(struct test *t, unsigned long v)
> {
> 	t->b = v;
> }
>
> int main(void)
> {
> 	struct test t;
> 	
> 	set(&t, 10);
>
> 	return 0;
> }
>

(Continue reading)

headers

Andi Kleen | 28 May 2011 17:34

[PATCH] Disable -fconserve-stack on ARM

Here's a untested but straight forward patch to disable it.
-Andi

---

Disable -fconserve-stack on ARM

There are reports that -fconserve-stack misaligns variables on the stack.
Disable it for ARM to work around this gcc bug.

Signed-off-by: Andi Kleen <ak <at> linux.intel.com>

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 25750bc..0883cff 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
 <at>  <at>  -41,6 +41,10  <at>  <at>  ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
 KBUILD_CFLAGS	+=-fstack-protector
 endif

+# ARM gcc developers unfortunately broke -fconserve-stack. It misaligns
+# variables on the stack
+KBUILD_CFLAGS += $(call cc-option,-fno-conserve-stack)
+
 ifeq ($(CONFIG_CPU_BIG_ENDIAN),y)
 KBUILD_CPPFLAGS	+= -mbig-endian
 AS		+= -EB

headers

Catalin Marinas | 31 May 2011 18:30

Re: [PATCH] Disable -fconserve-stack on ARM

On Sat, May 28, 2011 at 04:34:17PM +0100, Andi Kleen wrote:
> Disable -fconserve-stack on ARM
> 
> There are reports that -fconserve-stack misaligns variables on the stack.
> Disable it for ARM to work around this gcc bug.
> 
> Signed-off-by: Andi Kleen <ak <at> linux.intel.com>
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 25750bc..0883cff 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
>  <at>  <at>  -41,6 +41,10  <at>  <at>  ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
>  KBUILD_CFLAGS  +=-fstack-protector
>  endif
> 
> +# ARM gcc developers unfortunately broke -fconserve-stack. It misaligns
> +# variables on the stack
> +KBUILD_CFLAGS += $(call cc-option,-fno-conserve-stack)

Didn't work, on the gcc command line we get -fno-conserve-stack followed
by -fconserve-stack from the top makefile and it seems that the latter
takes priority.

--

-- 
Catalin

headers

Andi Kleen | 31 May 2011 20:01

Re: [PATCH] Disable -fconserve-stack on ARM

> Didn't work, on the gcc command line we get -fno-conserve-stack followed
> by -fconserve-stack from the top makefile and it seems that the latter
> takes priority.

Ah ok need to move it up then too in the top level Makefile.
Like this.

-Andi

---
Disable -fconserve-stack on ARM v2

There are reports that -fconserve-stack misaligns variables on the stack.
Disable it for ARM to work around this gcc bug.

v2: Move top level flags definition up
Signed-off-by: Andi Kleen <ak <at> linux.intel.com>

diff --git a/Makefile b/Makefile
index 529d93f..08d848f 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -564,6 +564,10  <at>  <at>  else
 KBUILD_CFLAGS	+= -O2
 endif

+# conserve stack if available
+# do this early so that an architecture can override it.
+KBUILD_CFLAGS   += $(call cc-option,-fconserve-stack)
+

(Continue reading)

headers

Catalin Marinas | 2 Jun 2011 15:08

Re: [PATCH] Disable -fconserve-stack on ARM

On Tue, May 31, 2011 at 07:01:07PM +0100, Andi Kleen wrote:
> Disable -fconserve-stack on ARM v2
> 
> There are reports that -fconserve-stack misaligns variables on the stack.
> Disable it for ARM to work around this gcc bug.
> 
> v2: Move top level flags definition up
> Signed-off-by: Andi Kleen <ak <at> linux.intel.com>

It seems to disable the -fconserve-stack on ARM.

Tested-by: Catalin Marinas <catalin.marinas <at> arm.com>