Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"

[Dave Martin]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/