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!