Re: SBCL 2.6.1 SIGILL during make-target-2 warm init on riscv64/linux/musl

Finally, I figured out the original riscv problem.
$RA gets moved into a non-descriptor register, never spilled onto the
control stack, and the function does not get pinned.
I made riscv/loongarch always spill RA. Whoever wants to make RA
always stay in RA until it's spilled to the CS is welcome to optimize
it.

Here's a test function:
(defun c (n h) (values n h))
(defun n (m) (declare (fixnum m)) (c (make-array 10000) (> m 20)))
(defun l () (declare (optimize speed (debug 0) (safety 0))) (n 0))
(loop (l)))

On Fri, Feb 20, 2026 at 3:47 AM Stas Boukarev <[email protected]> wrote:
>
> I have made some changes to the register pinning process. And it seems
> to have fixed a --gc-stress crash on riscv (and on loongarch).
> But the riscv machine I have access to is so slow I can't really make
> --gc-stress tell anything.
> Maybe someone who has a fast riscv machine can try --gc-stress.
>
> On Sat, Feb 14, 2026 at 1:44 AM Charles Zhang <[email protected]> wrote:
> >
> > I agree with Stas, it’s most likely a GC thing. Threaded builds were always a bit flaky because of that, and I was never sure after removing LRA whether on-stack code really does get pinned correctly or not.
> >
> > Although this seems like a regression - I think I had the test suite at least flushing through at one point.
> >
> > On Friday, February 13, 2026, 10:26 PM, Stas Boukarev <[email protected]> wrote:
> >
> > I'm willing to wager that memory just moves away from under it.
> >
> > E.g. I run ./run-tests.sh debug.* --gc-stress on riscv and get
> >
> > Unhandled TYPE-ERROR in thread #<SB-THREAD:THREAD tid=69302 "main
> > thread" RUNNING
> >                                   {4F96AC73}>:
> >   The value
> >     0
> >   is not of type
> >     SB-C:TN
> >   when binding SB-C::Y
> >
> > On Sat, Feb 14, 2026 at 12:19 AM Christophe Rhodes via Sbcl-devel
> > <[email protected]> wrote:
> > >
> > > SIGILL can mean a number of different things.  One thing it can mean is
> > > that we have managed to encode an illegal instruction for your hardware.
> > > If that's the case, you could probably at least verify that by attaching
> > > gdb to the process and disassembling the memory around the faulting
> > > instruction: does most of it look like plausible Lisp code and there's
> > > just one bogus instruction?  Then that's probably it.
> > >
> > > Another thing it can mean is that our assembler is mostly fine, but
> > > somehow the Lisp process has decided to jump into things that aren't
> > > meant to be machine code (header data, error encoding, that kind of
> > > thing).  That's probably quite painful to start debugging: where have we
> > > jumped from?  If this looks like it might be the case, I would probably
> > > start by checking to see if *any* riscv/sbcl builds on your hardware: if
> > > none does, then it's something more fundamental, but if there is an SBCL
> > > that builds, you could bisect to find the first version that doesn't,
> > > and stare suspciously at that change.  If no version of SBCL runs on
> > > your hardware, I'd perhaps try swapping out the C library, because I'm
> > > not very familiar with musl, to see if that makes a difference.
> > >
> > > A third thing it might mean is that your hardware requires more
> > > instruction cache flushing (I think the SBCL term is
> > > "sanctify-for-execution") than we are currently doing.  (Some hardware
> > > has separate and non-coherent data and instruction caches to memory, so
> > > writing data to memory that is intended later to be executed, as SBCL
> > > does, requires us to make sure that the instruction cache will pick up
> > > the new stuff).
> > >
> > > Best wishes,
> > >
> > > Christophe
> > >
> > > Will Sinatra <[email protected]> writes:
> > >
> > > > Building SBCL 2.6.1 from source on native riscv64 hardware using ECL
> > > > 24.5.10 as the cross-compilation host results in a SIGILL (signal 4)
> > > > crash during the make-target-2 warm init phase. The cross-compilation
> > > > (make-host-1) and genesis complete successfully, and the freshly built
> > > > SBCL boots and begins warm compilation, but crashes after compiling
> > > > src/code/room.lisp.
> > > >
> > > > Build progression
> > > >
> > > > make-host-1 (cross-compilation via ECL): Completes successfully.
> > > > make-host-2 / genesis: Completes successfully. Cold core is generated.
> > > > Genesis passes are consistent.
> > > > make-target-2(warm init): The freshly built SBCL boots from the cold
> > > > core and begins compiling. During warm init, three missing foreign
> > > > symbols are reported at startup:
> > > >
> > > > Missing required foreign symbol 'fun_end_breakpoint_trap'Missing
> > > > required foreign symbol 'fun_end_breakpoint_end'Missing required
> > > > foreign symbol 'fun_end_breakpoint_guts'
> > > >
> > > > Despite these warnings, cold init proceeds and warm compilation
> > > > begins. The build successfully compiles many files (including the
> > > > disassembler) but crashes immediately after compiling
> > > > src/code/room.lisp.
> > > >
> > > > Crash output
> > > >
> > > > ; compiling file "src/code/room.lisp" (written 26 JAN 2026 09:10:11 PM):
> > > >
> > > > ; wrote /builds/.../obj/from-self/src/code/room.fasl
> > > > ; compilation finished in 0:00:01.999
> > > > CORRUPTION WARNING in SBCL pid 2678 tid 2678:
> > > > Signal 4 received (PC: 0x518e6f14)
> > > > Exiting.
> > > > Error opening /dev/tty: No such device or address
> > > > ldb> Welcome to LDB, a low-level debugger for the Lisp runtime environment.
> > > > Command exited with non-zero status 1
> > > >
> > > > Signal 4 is SIGILL. The crash PC (0x518e6f14) falls within the dynamic
> > > > space (base 0x4F000000), indicating the illegal instruction is in
> > > > compiled Lisp code rather than the C runtime.
> > > >
> > > > The full build log is attached, and any suggestions on how to proceed
> > > > are sincerely appreciated!
> > >
> > >
> > > _______________________________________________
> > > Sbcl-devel mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> >
> >
> >
> > _______________________________________________
> > Sbcl-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel


_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel