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

Christophe Rhodes via Sbcl-devel <[email protected]> Fri, 13 Feb 2026 21:18:08 +0000
Newsgroups gmane.lisp.steel-bank.devel
Message-ID <[email protected]>
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!