All of lore.kernel.org
 help / color / mirror / Atom feed
From: lsanfil@marvell.com (sanfilippo)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"
Date: Wed, 4 Mar 2015 12:40:34 +0100	[thread overview]
Message-ID: <54F6EF32.7080306@marvell.com> (raw)
In-Reply-To: <20150303144130.GB5177@e103592.cambridge.arm.com>

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 kernel.org. What 
I do is:

- configure the kernel with mvebu_v5_defconfig
- compile it

However this issue occurs (so far) only with this special toolchain:
http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2

If you like you can try this yourself. I am sure that you will get the 
same results.

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 vmlinux.lds.h 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.

Regards,
Lino

WARNING: multiple messages have this Message-ID (diff)
From: sanfilippo <lsanfil@marvell.com>
To: Dave Martin <Dave.Martin@arm.com>
Cc: <linux@arm.linux.org.uk>, <linux-arm-kernel@lists.infradead.org>,
	<LinoSanfilippo@gmx.de>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section"
Date: Wed, 4 Mar 2015 12:40:34 +0100	[thread overview]
Message-ID: <54F6EF32.7080306@marvell.com> (raw)
In-Reply-To: <20150303144130.GB5177@e103592.cambridge.arm.com>

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 kernel.org. What 
I do is:

- configure the kernel with mvebu_v5_defconfig
- compile it

However this issue occurs (so far) only with this special toolchain:
http://www.plugcomputer.org/405/us/gplugd/tool-chain/arm-marvell-linux-gnueabi.tar.bz2

If you like you can try this yourself. I am sure that you will get the 
same results.

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 vmlinux.lds.h 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.

Regards,
Lino

  reply	other threads:[~2015-03-04 11:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-02 10:01 [RFC PATCH 0/1] Wrong structure alignment due to compiler attribute "section" Lino Sanfilippo
2015-03-02 10:01 ` Lino Sanfilippo
2015-03-02 10:01 ` [RFC PATCH 1/1] ARM: Ensure correct structure alignment when using " Lino Sanfilippo
2015-03-02 10:01   ` Lino Sanfilippo
2015-03-03 14:41 ` [RFC PATCH 0/1] Wrong structure alignment due to " Dave Martin
2015-03-03 14:41   ` Dave Martin
2015-03-04 11:40   ` sanfilippo [this message]
2015-03-04 11:40     ` sanfilippo
2015-03-04 14:35     ` Dave Martin
2015-03-04 14:35       ` Dave Martin
2015-03-04 16:29       ` Lino Sanfilippo
2015-03-04 16:29         ` Lino Sanfilippo
2015-03-05 12:26         ` Dave Martin
2015-03-05 12:26           ` Dave Martin
2015-03-05 13:20           ` Lino Sanfilippo
2015-03-05 13:20             ` Lino Sanfilippo
2015-03-05 13:47             ` Dave Martin
2015-03-05 13:47               ` Dave Martin
2015-03-05 15:32               ` Lino Sanfilippo
2015-03-05 15:32                 ` Lino Sanfilippo
2015-03-05 17:33                 ` Dave Martin
2015-03-05 17:33                   ` Dave Martin
2015-03-06 14:02                   ` Lino Sanfilippo
2015-03-06 14:02                     ` Lino Sanfilippo
2015-03-06 18:20                     ` Lino Sanfilippo
2015-03-06 18:20                       ` Lino Sanfilippo
2015-03-22  0:56                       ` Lino Sanfilippo
2015-03-22  0:56                         ` Lino Sanfilippo
2015-03-24 12:07                         ` Dave Martin
2015-03-24 12:07                           ` Dave Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F6EF32.7080306@marvell.com \
    --to=lsanfil@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.