From: Patrick Menschel <menschel.p@posteo.de>
To: Rong Chen <rong.a.chen@intel.com>
Cc: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>,
Oliver Hartkopp <socketcan@hartkopp.net>,
kernel test robot <lkp@intel.com>,
kbuild-all@lists.01.org, open list <linux-kernel@vger.kernel.org>,
Marc Kleine-Budde <mkl@pengutronix.de>,
linux-can <linux-can@vger.kernel.org>
Subject: Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(struct canfd_frame, len) || offsetof(struct can_frame, data) != offsetof(struc...
Date: Tue, 23 Mar 2021 08:26:55 +0100 [thread overview]
Message-ID: <f215591d-1d5f-b5ae-38fe-4f6407bb2116@posteo.de> (raw)
In-Reply-To: <52e57719-7b55-b21a-5e30-4be2fb4e776c@intel.com>
Am 23.03.21 um 07:06 schrieb Rong Chen:
>>>> Ugh! Why did the compiler extend the space for the union to 4 bytes?!?
>> Just a random idea but maybe the added padding is due to some
>> kind of odd intrication with the __attribute__((__aligned__(8)))
>> just below? Does this reproduce if we remove the
>> __attribute__((__aligned__(8)))?
>
> Here is the layout without __attribute__((__aligned__(8))),
> the union is still extended to 4 bytes:
>
> struct can_frame {
> canid_t can_id; /* 0 4 */
> union {
> __u8 len; /* 4 1 */
> __u8 can_dlc; /* 4 1 */
> }; /* 4 4 */
> __u8 __pad; /* 8 1 */
> __u8 __res0; /* 9 1 */
> __u8 len8_dlc; /* 10 1 */
> __u8 data[8]; /* 11 8 */
>
> /* size: 20, cachelines: 1, members: 6 */
> /* padding: 1 */
> /* last cacheline: 20 bytes */
> };
>
> Best Regards,
> Rong Chen
Hi,
I would suggest a try with __attribute__((__aligned__(8))) only on
can_frame, not on data[8].
If the structure length is a multiple of 8, the compiler should
recognize this and keep the union a single byte in favor of an array
configuration of that struct.
The __attribute__((__aligned__(8))) on data[8] has strange propagation
effects upwards.
If the attributes are really necessary, I would suggest to have both
__attribute__((packed))
__attribute__((__aligned__(8)))
on structure level instead of inside, so no padding happens inside the
structure while the structure itself is aligned.
Using aligned and packaged inside a structure may be contradictive to
the compiler.
This reminds me of the alignment/gap issue with my python3
implementation of bcm message while alternating between X86_64 and
ARMHF. Using c_types was a mess but bytestrings worked in the end.
Be aware native alignment apparently is 4 on armhf linux and 8 on X86_64
linux.
https://marc.info/?l=linux-can&m=161251622904527&w=2
https://gitlab.com/Menschel/socketcan/-/commit/afc6744129448ae4333629fc0297808dd42e3530#e522710a8423075cfd1147ae6b7f44facac3ffb0_133_132
Best Regards,
Patrick Menschel
next prev parent reply other threads:[~2021-03-23 7:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-20 20:43 kernel test robot
2021-03-21 14:19 ` Oliver Hartkopp
2021-03-22 8:52 ` [kbuild-all] " Rong Chen
2021-03-22 16:24 ` Oliver Hartkopp
2021-03-23 2:54 ` Rong Chen
2021-03-23 5:46 ` Vincent MAILHOL
2021-03-23 6:06 ` Rong Chen
2021-03-23 7:26 ` Patrick Menschel [this message]
2021-03-23 7:34 ` Marc Kleine-Budde
2021-03-23 7:45 ` Oliver Hartkopp
2021-03-23 8:32 ` Oliver Hartkopp
2021-03-23 8:54 ` Marc Kleine-Budde
2021-03-23 8:59 ` Rong Chen
2021-03-23 9:35 ` Rong Chen
2021-03-23 11:36 ` Rasmus Villemoes
2021-03-23 12:49 ` Oliver Hartkopp
2021-03-23 14:00 ` Rasmus Villemoes
2021-03-23 18:59 ` Oliver Hartkopp
2021-03-23 20:54 ` Rasmus Villemoes
2021-03-24 9:09 ` Oliver Hartkopp
2021-03-24 9:57 ` Marc Kleine-Budde
2021-03-29 7:01 ` Marc Kleine-Budde
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=f215591d-1d5f-b5ae-38fe-4f6407bb2116@posteo.de \
--to=menschel.p@posteo.de \
--cc=kbuild-all@lists.01.org \
--cc=linux-can@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mailhol.vincent@wanadoo.fr \
--cc=mkl@pengutronix.de \
--cc=rong.a.chen@intel.com \
--cc=socketcan@hartkopp.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®