On Thu, 25 Aug 2022 at 20:01, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:
>
> Hi Ard,
>
> On Thu, Aug 25, 2022 at 2:56 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > On Thu, 25 Aug 2022 at 14:21, Yann Sionneau <ysionneau@xxxxxxxxx> wrote:
> > > Well, I am not completely sure about that. See my cover letter, previous
> > > mechanism for symbol CRC was actually enforcing the section alignment to
> > > 4 bytes boundary as well.
>
> Yes, because else it may become 2-byte aligned on m68k.
>
> > > Also, I'm not sure it is forbidden for an architecture/compiler
> > > implementation to actually enforce a stronger alignment on u32, which in
> > > theory would not break anything.
> > >
> >
> > u32 is a Linux type, and Linux expects natural alignment (and padding).
>
> Is it? You probably mean its alignment should not be larger than
> 4 bytes? Less has been working since basically forever.
>
You are quite right. of course. And indeed, the issue here is padding
not alignment.
> > So if your toolchain/architecture violates this rule, I suggest you
> > typedef u32 to 'unsigned int __aligned(4)' explicitly. so that things
> > don't break in other places.
> >
> > However, even then, I am highly skeptical. This really seems like an
> > issue in your toolchain that could cause problems all over the place.
> >
> > > But in this precise case it does break something since it will cause
> > > "gaps" in the end result vmlinux binary segment. For this to work I
> > > think we really want to enforce a 4 bytes alignment on the section.
> >
> > You are addressing one of many potential issues that could be caused
> > by this, so I don't think this patch is a good idea tbh.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
