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
next prev parent 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.