Re: riscv64 libc string function patch set -- how to proceed?

Hi Mitchell,

Am Mon, Aug 11, 2025 at 01:13:58PM -0300 schrieb Mitchell Horne:
> 
> 
> On 8/6/25 06:06, Robert Clausecker wrote:
> > Greetings!
> > 
> > As part of last years GSoC, strajabot@ implemented [1] assembly
> > variants of some of the libc string functions.  As we do not have
> > support for RVV nor for fine-grained instruction set extension
> > detection, it was decided to just use the basic instruction set
> > with no extension.  So it's all SWAR techniques.
> > 
> > Back then we decided to do the same acceptance test I did for
> > the AArch64 functions and the amd64 functions: build all ports
> > with and without the patch set and see if anything changes.
> > I started to do so in late 2024, but my build box kept crashing.
> > Eventually I discovered that this crash was in fact a livelock
> > in the OpenSBI firmware that would also occur on emulator [2],
> > preventing any progress on the acceptance test.
> > 
> > These are the patches involved.  You can find them all in one
> > branch on strajabot@'s github [3]:
> > 
> >     D47275 D46230 D46139 D46023 D46047 D45730 D45693
> > 
> > They pass our test suite and seem fine.  We have tried to hook
> > them up to the glibc test suite, but that test suite is so
> > annoying to work with that it is not really feasible to do so.
> > It does not seem like the planned acceptance test can be
> > completed at all in face of PR 284743, and given the lack of
> > interest in getting this issue fixed, I don't see a possibility
> > of getting the acceptance test completed.
> > 
> > How shall we proceed with these patches?
> > 
> 
> Hi Robert,
> 
> I would like see this work integrated. Certainly it would be more
> valuable in the tree than stuck in review.
> 
> Building a full/large suite of ports would be a comprehensive test, but
> given the major blockers here I see no reason to insist on it.
> 
> Are you able to roughly quantify/estimate the risk? I.e. how much
> coverage do we get from the FreeBSD test suite, and other tests you have
> already exercised on these implementations? Would a self-hosted
> buildworld add any value at this point?

I already self-host this RISC-V box, so buildkernel/buildworld works fine
with the patched system.  No complaints there.  As for the test suite, well
it's kind of a mixed bag.  Some unit tests are comprehensive, others are
somewhat primitive.  In the past I updated the test suite every time I
found some error in my amd64 code that it didn't catch, yet these bugs kept
happening every once in a while.  One bug in particular was never caught
in the wild until I deliberately built a unit test to get at it.  Now the
riscv64 code passes all these tests, so if it has bugs, they are all of the
new and exciting variety.

That said, I am somewhat sure that if there are bugs, they are hard to
trigger.  Given that these are all SWAR implementations, there may be
arithmetic issues that are very hard to catch.

> The way I see it we have two options:
>  1. Merge the changes now ahead of 15.0
>  2. Merge them after stable/15 branches, keeping them only in main
> 
> Option 2 is more conservative, but the riscv user-base is so small that
> we might benefit more from merging it now. Clearly, the platform still
> has some major bugs/limitations in the base system, so I don't feel the
> need to be precious about our release images.
> 
> I appreciate that any latent bugs in these primitives may be nasty to
> debug/pinpoint in the future.

I would prefer to go with option (1).  "Given enough eyeballs" and all that.
And given that nobody cares about 284743 either, I guess i won't break
any production setup with my changeset.

> I am out-of-practice with RISC-V assembly, so I can't offer any real
> review of the implementations. I will look over the changes and give my
> rubber-stamp approval, but really I can only defer to your expertise here.
> 
> To summarize: I will look it over, but how we proceed with this project
> is up to you.

Thank you for this offer.

> Best,
> Mitchell

Yours,
Robert Clausecker

-- 
()  ascii ribbon campaign - for an encoding-agnostic world
/\  - against html email  - against proprietary attachments