Re: [PATCH] tools/nolibc: sh: enter _start_c with jsr instead of bsr

["Thomas Weißschuh" <linux@weissschuh.net>]

On 2026-10-23 18:20:55+0200, Willy Tarreau wrote:
> On Fri, Oct 23, 2026 at 05:53:51PM +0200, Thomas Weißschuh wrote:
> > On 2026-10-23 07:09:55+0200, Willy Tarreau wrote:
> > (...)
> > > > > Replace bsr with a calculation of the effective address of
> > > > > _start_c and jsr.
> > > > > 
> > > > > Tested on QEMU and real SH4 and SH4a machines.
> > > > > 
> > > > > Signed-off-by: Daniel Palmer <daniel@0x0f.com>
> > > > > ---
> > > > > 
> > > > > I'm no SuperH asm expert but this works for me. :)
> > > > > Maybe there is a way in C to get _start and _start_c to always
> > > > > be close together that would avoid this entirely?
> > > > 
> > > > That would be my preference, too.
> > > > 
> > > > Maybe one of these works:
> > > > 
> > > > 1) Put both _start() and _start_c() in a dedicated .text subsection.
> > > > 
> > > > Apparently the default GNU ld linkerscript contains '*(SORT(.text.sorted.*))'.
> > > > So if we use .text.sorted.nolibc_start for both functions they should
> > > > end up next to each other.
> > > > See https://sourceware.org/binutils/docs/ld/Input-Section-Wildcards.html.
> > > > 
> > > > 2) Put _start() *into* _start_c:
> > > > 
> > > > diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h
> > > > index 714256228914..ebcd0ea2b9f2 100644
> > > > --- a/tools/include/nolibc/crt.h
> > > > +++ b/tools/include/nolibc/crt.h
> > > > @@ -115,6 +115,19 @@ void _start_c(long *sp)
> > > >                 (*--dtor_func)();
> > > > 
> > > >         exit(exitcode);
> > > > +
> > > > +       __asm__ volatile (
> > > > +               ".global _start\n"           /* The C function will have a prologue,         */
> > > > +               ".type _start, @function\n"  /* corrupting "sp"                              */
> > > > +               ".weak _start\n"
> > > > +               "_start:\n"
> > > > +
> > > > +               "mov sp, r4\n"               /* save argc pointer to r4, as arg1 of _start_c */
> > > > +               "bsr _start_c\n"             /* transfer to c runtime                        */
> > > > +               "nop\n"                      /* delay slot                                   */
> > > > +
> > > > +               ".size _start, .-_start\n"
> > > > +       );
> > > >  }
> > > > 
> > > >  #endif /* NOLIBC_NO_RUNTIME */
> > > > 
> > > > But that for all architectures, using macros etc.
> > > > 
> > > > If the .text.sorted. solution works, I'd prefer that.
> > > 
> > > Do be honest, I think that Daniel's proposal remains the most maintainable
> > > one. We rarely touch the start code, and having only a few do arch-
> > > specific tricks is likely less of a burden for the long term than
> > > relying on linker's ordering of sections, or starting to play macro
> > > games. And it gets a chance that someone more familiar with that arch
> > > improves it later if needed. But I'm not opiniated on this at all :-)
> > 
> > I fear that we will have the same problems in other architectures.
> > And for those we'll also need custom assembly. While the mechanisms
> > above would not need that.
> 
> But all archs support indirect calls one way or another. Normally we
> should be able to do the equivalent of placing an absolute value in a
> storage area, load it in a register and branch to it at least.

Of course it is possible to do. But it differs between architectures and
somebody will have to write and maintain that assembly code.

> For me, sorted sections are most likely meant to be used to group code by
> locality, not to guarantee that branch offsets will always remain
> small enough for all architectures.

Exactly this locality should provide small enough branch offsets.
The section ".text.sorted.nolibc_crt" should only ever have two functions:
Our _start() and _start_c().
While there won't be a formal guarantee that the architecture's branch
offsets will be able to handle those, I find it hard to imagine that
they won't.

> An indirect call on the other hand is well defined, standard and can
> be adopted where needed at the cost of only 4 or 8 bytes in the
> startup code.

Its a few more bytes, not that it really matters.
* 3 additional instructions -> 6 bytes
* The embedded offset -> 4 bytes
* Up to 3 bytes of alignment

The adoption will require additional fiddling with assembly.

Maybe we let Daniel break the tie? :-)


Thomas