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

[Willy Tarreau]

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@xxxxxxxx>
> > > > ---
> > > > 
> > > > 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. 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. 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.

Willy