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

[Willy Tarreau <w@1wt.eu>]

Hi Daniel,

On Sat, Oct 24, 2026 at 02:16:10PM +0900, Daniel Palmer wrote:
> Hi Willy, Thomas
> 
> On Sat, 24 Oct 2026 at 03:35, Willy Tarreau <w@1wt.eu> wrote:
> > > Maybe we let Daniel break the tie? :-)
> 
> mmm I have the same big binary (Quake using nolibc + a thin DRM/KMS +
> ALSA layer, some libm bits from musl) on 32 bit ARM and x86-64 and
> they were fine so my gut feeling would be that this is an SH issue and
> a few extra bytes is fine for such a niche arch.

x86 can call 32-bit displacements, so you have some margin there ;-)

> On SH this also seems to happen for much more normal binaries if you
> enable LTO and get unlucky which points me towards letting the SH
> entry code deal with it.
> 
> But also I'm still working on the static PIE thing so nolibc can
> create binaries that nommu can run and in that case it would probably
> be helpful for all of the code that runs before relocation to be close
> together.
> 
> I'll have a go at the ld solution and see what happens.

OK!

> Slightly different topic but related: Another thing on my pile of
> patches is some stuff to extend memcpy() slightly so it generates
> word-by-word copies where possible without passing -O3. This helps
> m68k and SH a lot but everyone would end up with the extra bytes for
> the word-by-word copy loop and the check if fallback to byte-by-byte
> is needed. Would wrapping that in something like "#if
> NOLIBC_FAST_MEMCPY" be acceptable?

I've been thinking about similar things a few times, and I think that
for such cases where we implementa naive function for size purposes, we
could also rely on #ifdef __OPTIMIZE_SIZE__ to keep the small one and
switch to the faster one otherwise. That way we can respect each user's
expectations.

Willy