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

[Thomas Weißschuh]

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.

The sorted linker sections should be stable. They have been introduced
as an explicit feature by GNU ld. They are fairly new (2019), but they
should fall back to non-sorted linking just fine for older linkers.