From: Kirill A. Korinsky <kirill@korins.ky>
Subject: Re: llvm/sparc64: match BFD -N alignment
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: deraadt@openbsd.org, semarie@online.fr, robert@openbsd.org, tech@openbsd.org
Date: Tue, 18 Aug 2026 23:12:07 +0200

On Tue, 18 Aug 2026 22:59:44 +0200,
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
> > Date: Tue, 18 Aug 2026 22:15:49 +0200
> > From: Kirill A. Korinsky <kirill@korins.ky>
> > 
> > On Tue, 18 Aug 2026 21:55:34 +0200,
> > Kirill A. Korinsky <kirill@korins.ky> wrote:
> > > 
> > > On Tue, 18 Aug 2026 19:56:28 +0200,
> > > Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > 
> > > > > From: "Theo de Raadt" <deraadt@openbsd.org>
> > > > > Date: Tue, 18 Aug 2026 10:33:35 -0600
> > > > > 
> > > > > Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > > 
> > > > > > > OK deraadt, but now that it's serious kettenis may have other nits.
> > > > > > > The conditions look correct to me and I don't think anything outside
> > > > > > > sys/arch/sparc64/stand uses the ld options which use this so the effects
> > > > > > > are tightly constrained.
> > > > > > 
> > > > > > I have a feeling that this is trying to work around an issue that can
> > > > > > be fixed by passing the right command line arguments and/or a fairly
> > > > > > simple linker script.  Please let me see if I can figure that out
> > > > > > before committing this.
> > > > > 
> > > > > In the old days, did nmagic binaries really do 1MB padding?
> > > > > I doubt it.  So it seems like an oversight.
> > > > 
> > > > The padding seems to be a consequence of mixing -N with -Ttext.
> > > > 
> > > > Kirill, can you try replacing
> > > > 
> > > >   "-Ttext ${RELOC}"
> > > > 
> > > > with
> > > > 
> > > >   "--image-base=0x${RELOC}"
> > > > 
> > > > ?
> > > > 
> > > > And maybe you can put your current ofwboot binary (the one produces by
> > > > your midified version of ld.lld) somewhere such that I can take a look
> > > > at it?
> > > > 
> > > 
> > > Yes, replacing -Ttext ${RELOC} by --image-base=0x${RELOC} as:
> > > 
> > > RCS file: /cvs/src/sys/arch/sparc64/stand/ofwboot/Makefile,v
> > > diff -u -p -r1.29 Makefile
> > > --- ofwboot/Makefile    30 Jan 2025 21:46:25 -0000      1.29
> > > +++ ofwboot/Makefile    18 Aug 2026 19:02:45 -0000
> > > @@ -73,7 +73,7 @@ CPPFLAGS+=    -DSOFTRAID
> > >  .endif
> > > 
> > >  ${PROG}: ${OBJS} ${LIBSA} ${LIBZ}
> > > -       ${LD} -N -Ttext ${RELOC} -e ${ENTRY} -o ${PROG} -nopie -znorelro \
> > > +       ${LD} -N --image-base=0x${RELOC} -e ${ENTRY} -o ${PROG} -nopie -znorelro \
> > >             ${OBJS} -L${LIBSADIR} ${LIBSA} \
> > >             -L${LIBZDIR} ${LIBZ}
> > > 
> > > 
> > > leads to ofwboot without padding. Binaries are here:
> > > https://kirill.korins.ky/pub/sparc64-ofwboot/
> > > 
> > 
> > ... and ofwboot with --image-base can't boot in qemu as:
> 
> can't? or can?  Because...
> 
> > OpenBIOS for Sparc64
> > Configuration device id QEMU version 1 machine id 0
> > kernel cmdline
> > CPUs: 1 x SUNW,UltraSPARC-IIi
> > UUID: 00000000-0000-0000-0000-000000000000
> > Welcome to OpenBIOS v1.1 built on Aug 18 2026 12:04
> >   Type 'help' for detailed information
> > Trying disk...
> > Not a bootable ELF image
> > Not a bootable a.out image
> > 
> > Loading FCode image...
> > Loaded 6888 bytes
> > entry point is 0x4000
> > Evaluating FCode...
> > OpenBSD IEEE 1275 Bootblock 2.1
> > ..>> OpenBSD BOOT 1.30
> > Trying bsd...
> > Booting /pci@1fe,0/pci@1,1/ide@3/ide@0/disk@0/bsd
> > 10567496@0x1000000+184@0x1a13f48+146540@0x1c00000+4047764@0x1c23c6c
> > symbols @ 0xfeda2400 548154+165+710688+500011 start=0x1000000
> 
> Those last 5 lines are ofwboot output...
> 

Yes, it starts to boot and hangs.

-- 
wbr, Kirill