lkml.org 
[lkml]   [2015]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"
On Wed, Mar 04, 2015 at 05:29:14PM +0100, Lino Sanfilippo wrote:
> On 04.03.2015 15:35, Dave Martin wrote:
>
> >
> >Try
> >
> >rm drivers/clk/mvebu/kirkwood.o
> >make ARCH=arm KBUILD_CFLAGS_KERNEL=-save-temps drivers/clk/mvebu/kirkwood.o
> >
> >(abuse of KBUILD_CFLAGS_KERNEL here, but it's empty by default, and
> >I'm too lazy to copy-paste command lines...)
> >
> >
> >The compiler will split out the compiled assembly code in kirkwood.s:
> >
> >Look for ".align" directives between the start of the affected section
> >and the start of the next section (next .section directive).
> >
> >Here, we just have .align 2, which is the expected correct value
> >(i.e., align __of_table_mv88f6180_clk on a 2^2 = 4 byte boundary).
> >
> >A different value here may indicate a bug in the compiler, because
> >you observed that gcc _thinks_ that __alignof__ is 4 for the struct
> >in this section even in the failing case.
>
> Ok, this is the result for the assembly:
>
> .section __clk_of_table,"a",%progbits
> .align 3
> .type __of_table_mv88f6180_clk, %object
> .size __of_table_mv88f6180_clk, 196
> __of_table_mv88f6180_clk:
> .space 64

[...]

> Very interesting. It shows an .align 3 which explains alignment on
> 8 byte boundaries:
>
>
> c07630f8 T __clk_of_table
> c07630f8 t __of_table_fixed_factor_clk
> c07630f8 T __stop_kprobe_blacklist
> c07631c0 t __of_table_fixed_clk
> c0763288 t __of_table_gpio_gate_clk
> c0763350 t __of_table_mv88f6180_clk
>
> So this is indeed a compiler bug, right?

It certainly looks like the compiler is causing the issue somehow.

Whether this is a bug, a bug-like feature, a configuration issue,
or a combination of these is not clear.

If you know where to find the toolchain source, it might be worth
taking a look.

Cheers
---Dave



\
 
 \ /
  Last update: 2015-03-05 13:41    [W:0.075 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site