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

[Willy Tarreau]

On Fri, Oct 23, 2026 at 07:32:55PM +0200, Thomas Weißschuh wrote:
> > > 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.

It has worked till then at least so it should.

> > 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

It depends on the arch in fact but that remains the order of magnitude.

> The adoption will require additional fiddling with assembly.

Yes I agree.

> Maybe we let Daniel break the tie? :-)

The advantage of the ld-based one is that it should be the lowest effort
across all archs at once, so we should probably try with this one first.
If we later discover that it displaces the problem somewhere else, then
you can reconsider it and switch to the asm one.

Willy