mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®