[lkml]   [2015]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"
On Wed, Mar 04, 2015 at 12:40:34PM +0100, sanfilippo wrote:
> On 03.03.2015 15:41, Dave Martin wrote:
> Dave,
> thanks for your response.
> >For the element _size_ issue, I'm confused. On 32-bit, that
> >structure is clearly 196 bytes in size, with the alignment requirement
> >of void * (4 bytes)... so there's no clear reason why the linker
> >shouldn't be inserting extra padding.
> >
> >I can't reproduce this with my current tools (upstream binutils-2.24,
> >gcc-4.9.2).
> >
> >
> >Can you try to track down where this discrepancy is coming from?
> >
> >i.e.,
> >
> > * If you're juggling with multiple kernel trees, make sure there
> > are not differences between them that could be causing this, such
> > as changes to linker scripts or header files that are involved
> > in building these arrays.
> I can reproduce this with a vanilla kernel (3.19) from
> What I do is:
> - configure the kernel with mvebu_v5_defconfig
> - compile it
> However this issue occurs (so far) only with this special toolchain:
> If you like you can try this yourself. I am sure that you will get
> the same results.

Not really ;) Please see what you can find out first (see below).

> I tried the same with three other toolchains but with those the
> problem did not occur. I also tried other kernel configurations with
> that "problematic" toolchain, but also the problem did not occur any
> more.
> So I think its either a bug in that compiler/linker or the current
> solution in does not work correct under some special
> circumstances.
> >
> > * See what the input to the assembler looks like, with regard to
> > .align directives.
> >
> > * See what the alignment of the affected sections is in each individual
> > .o file.
> Not sure what exactly I should check here. Could you be a bit more precise?
> > * See what __alignof__(struct of_device_id) evaluates to.
> It evaluates to "4" even for the bad case.


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.

.section __clk_of_table,"a",%progbits
.align 2
.type __of_table_mv88f6180_clk, %object
.size __of_table_mv88f6180_clk, 196
.space 64
.ascii "marvell,mv88f6180-core-clock\000"
.space 99
.word kirkwood_clk_init
.type __of_table_kirkwood_clk, %object
.size __of_table_kirkwood_clk, 196
.space 64
.ascii "marvell,kirkwood-core-clock\000"
.space 100
.word kirkwood_clk_init
.section .rodata.str1.8,"aMS",%progbits,1

Also try:

arm-linux-gnueabi-objdump --headers drivers/clk/mvebu/kirkwood.o

Idx Name Size VMA LMA File off Algn


9 __clk_of_table 00000188 00000000 00000000 00000434 2**2

The "Algn" column should be 2**2. If it's not, but the assembly
code generated by the compiler looks correct, then there may be
a bug in the assembler.

If the .o file looks correct, it's possible that there is another
.o file containing data for this section that specifies a different
alignment.o -- try git grep CLK_OF_DECLARE to find the affected

It's also worth looking at __clk_of_table_end in drivers/clk/clk.o.
That gets merged in at the end of the same section, so if its
alignment is higher for some reason, that might be causing the


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