Re: [PATCH v2] certs: specify byte alignment

On Thu, 2026-08-06 at 15:32 +0100, Giuliano Procida wrote:
> Hi.
> 
> On Thu, 6 Aug 2026 at 14:51, Xi Ruoyao <[email protected]> wrote:
> > 
> > On Tue, 2025-09-23 at 10:08 +0100, Will Deacon wrote:
> > > On Tue, Sep 23, 2025 at 09:13:42AM +0100, Giuliano Procida wrote:
> > > > The alignments specified in system_certificates.S and
> > > > revocation_certificates.S are intended to be byte quantities.
> > > > 
> > > > However, the .align macro is architecture dependent and on arm64 it
> > > > behaves as .p2align. So use the .balign macro to avoid unnecessary
> > > > padding due to over-alignment.
> > > > 
> > > > Signed-off-by: Giuliano Procida <[email protected]>
> > > > ---
> > > >  certs/revocation_certificates.S | 4 ++--
> > > >  certs/system_certificates.S     | 8 ++++----
> > > >  2 files changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > Acked-by: Will Deacon <[email protected]>
> > > 
> > > Will
> > 
> > Hi,
> > 
> > It seems this patch somehow got lost?
> > 
> > Kexy found MIPS is specifically affected by the .align directive: on
> > MIPS it not only behaves as p2align and introduces a lot of extra
> > padding, but also moved before the __revocation_list_end label in the
> > case of
> > 
> > __revocation_list_end:
> > 
> >     .align 8
> > 
> > in revocation_certificates.S.  It seems the GNU assembler moves the
> > .align earlier to mimic the IRIX assembler behavior described at page
> > 110 of https://irix7.com/techpubs/007-2418-006.pdf:
> > 
> > 
> >     Labels immediately preceding an automatic or explicit
> >     alignment are also realigned. For example, foo:
> >     .align 3; .word 0 is the same as .align 3;
> >     foo: .word 0.
> > 
> > Kexy's AI proposed the same fix as this patch.  So maybe we should apply
> > it now?
> 
> That seems like a good idea. A colleague raised it again this week.
> We were considering just applying it to ACK and forgetting about upstream.
> I'm glad there's other interest though.
> 
> Could you raise this with the relevant maintainer?

Hmm, get_maintainers.pl shows David Howells and David Woodhouse are the
relevant maintainers and they are already CC'ed.  Or is the
get_maintainers.pl output inaccurate?


-- 
Xi Ruoyao <[email protected]>