Ports/gcc, Ports/llvm, Ports/tinycc: No working compiler on riscv64

[oskar-skog]

It's not possible to compile any C code on SerenityOS on rsicv64.

gcc immediately crashes

288.299 gcc(46): perror(): mmap reservation: Out of memory
288.725 gcc(46): VERIFICATION FAILED: false at ./Userland/Libraries/LibELF/DynamicLoader.cpp:353
288.866 [#0 gcc(46:46)]: Terminating gcc(46) due to signal 5
288.993 [#0 Finalizer Task(5:5)]: Backtrace:
0x00000000deadc0de  Kernel::ProcessorBase::switch_context(Kernel::Thread*&, Kernel::Thread*&) + 0x102
0x00000000deadc0de  Kernel::Scheduler::context_switch(Kernel::Thread*) + 0x134
0x00000000deadc0de  Kernel::Scheduler::pick_next() + 0x104
0x00000000deadc0de  Kernel::Scheduler::yield() + 0x80
0x00000000deadc0de  Kernel::Thread::die_if_needed() + 0x188
0x00000000deadc0de  Kernel::Thread::send_urgent_signal_to_self(unsigned char) + 0x2c4
0x00000000deadc0de  trap_handler + 0x572
0x00000000deadc0de  restore_context_and_sret + 0x0
0x0000000013cf36ae  /usr/lib/Loader.so + 0x96ae

==== Thread #0 (TID 46) ====
0x0000000013d02ac4: [Loader.so] AK::Function<bool (char)>::CallableWrapper<AK::ByteString::split_view(char, AK::SplitBehavior) const &::{lambda(char)#1}>::~CallableWrapper() +0x0 (Assertions.cpp:100)
0x0000000013cf36ad: [Loader.so] ELF::DynamicLoader::load_program_headers() +0xbd7 (DynamicLoader.cpp:353)
0x0000000013cf372b: [Loader.so] ELF::DynamicLoader::map() +0x4d (DynamicLoader.cpp:139)
0x0000000013ced6df: [Loader.so] ELF::map_library(AK::ByteString const&, int) +0xdf (DynamicLinker.cpp:118)
0x0000000013cf057f: [Loader.so] ELF::DynamicLinker::linker_main(AK::ByteString&&, int, bool, char**) +0x261 (DynamicLinker.cpp:687)
0x0000000013ceabfd: [Loader.so] _entry +0xd7 (main.cpp:235 => PrintfImplementation.h:320 => PrintfImplementation.h:377 => PrintfImplementation.h:381 => PrintfImplementation.h:601 => stdio.cpp:914)

If I increase the memory, it segfaults. (Tested 6 GiB)

==== Thread #0 (TID 45) ====
Page fault on Read at address 0xfffffffffffff840

0x000000000001791a: [/usr/local/bin/gcc] pthread_cancel +0x791a ()

206.056 [#0 gcc(45:45)]: Unrecoverable page fault, read from address V0xfffffffffffff840
206.066 [gcc(45:45)]: CRASH: CPU #0 Page Fault in userspace
206.108 [#0 gcc(45:45)]: scause:  Load page fault (0x000000000000000d)
206.113 [#0 gcc(45:45)]: sepc:    0x000000000001791a
206.124 [#0 gcc(45:45)]: stval:   0xfffffffffffff840
206.124 [#0 gcc(45:45)]: sstatus: SD UXL=64 XS=AllOff FS=Dirty VS=Initial SPP=User SPIE (0x8000000200006220)
206.160 [#0 gcc(45:45)]: ra=0x0000000013350bb2 sp=0x0000000827ef2190 gp=0x0000000000000000 tp=0x0000000000ad8000 fp=0x0000000827ef21f0
206.168 [#0 gcc(45:45)]: a0=0x000000000029a8d8 a1=0x000000000015a880 a2=0x000000000015a8c8 a3=0x000000000015a8c0 a4=0xfffffffffffff840 a5=0x0000000000299cc8 a6=0x00000000002998d0 a7=0x0000000000157548
206.195 [#0 gcc(45:45)]: t0=0x0000000000157358 t1=0x0000000000157358 t2=0x00000000002998f0 t3=0x0000000000157358 t4=0x00000000001ac858 t5=0x000000000015a830 t6=0x00000000002998a0
206.211 [#0 gcc(45:45)]: s1=0x00000000002504d8 s2=0x0000000000250548 s3=0x0000000013379070 s4=0x0000000013379070 s5=0x000000000000000a s6=0x0000000827ef24a8 s7=0x0000000000000004 s8=0x0000000000000000 s9=0x0000000000000001 s10=0x0000000b01b90070 s11=0x0000000227304d08
206.243 [#0 gcc(45:45)]: 0x000000000001791a  (?)

206.243 [#0 gcc(45:45)]: Userspace backtrace:
206.251 [#0 gcc(45:45)]: Kernel backtrace:
Kernel + 0x0000000000473956  Kernel::Process::crash(int, AK::Optional<Kernel::RegisterState const&>, bool) +0x1dc
Kernel + 0x0000000000453592  Kernel::handle_crash(Kernel::RegisterState const&, char const*, int, bool) +0x3d8
Kernel + 0x0000000000005d26  Kernel::PageFault::handle(Kernel::RegisterState&) +0x5ec
Kernel + 0x00000000004c263e  trap_handler +0x3d6
Kernel + 0x00000000004d3d76  restore_context_and_sret +0x0
206.473 [#0 Finalizer Task(5:5)]: Generating coredump for pid: 45
207.282 [#0 VFS Sync Task(4:4)]: Ext2FS: Flushed 18 blocks to disk
217.154 CrashDaemon(34): New coredump file: /tmp/coredump/gcc_45_1784048463
243.642 CrashReporter(46:47): Generating backtrace took 7442 ms

clang seems to compile fine, but can't link.
lld segfaults and then clang aborts after writing the error.

==== Thread #0 (TID 47) ====
Page fault on Read at address 0x0100000000000008

0x0000000d2c3a40f8: [/usr/local/bin/lld] std::unique_ptr<InProgressEntry, std::default_delete<InProgressEntry> >& llvm::SmallVectorImpl<std::unique_ptr<InProgressEntry, std::default_delete<InProgressEntry> > >::emplace_back<std::unique_pt
r<InProgressEntry, std::default_delete<InProgressEntry> > >(std::unique_ptr<InProgressEntry, std::default_delete<InProgressEntry> >&&) [clone .isra.0] +0x0 ()

1623.357 [#0 lld(47:47)]: Unrecoverable page fault, read from address V0x0100000000000008
1623.365 [lld(47:47)]: CRASH: CPU #0 Page Fault in userspace
1623.393 [#0 lld(47:47)]: scause:  Load page fault (0x000000000000000d)
1623.393 [#0 lld(47:47)]: sepc:    0x0000000d2c3a40f8
1623.426 [#0 lld(47:47)]: stval:   0x0100000000000008
1623.436 [#0 lld(47:47)]: sstatus: SD UXL=64 XS=AllOff FS=Dirty VS=Initial SPP=User SPIE (0x8000000200006220)
1623.455 [#0 lld(47:47)]: ra=0x0000000d2c3a4328 sp=0x0000001567192520 gp=0x0000000000000000 tp=0x0000000005a9d000 fp=0x0000001997870c40
1623.462 [#0 lld(47:47)]: a0=0x0100000000000000 a1=0x0000001567192548 a2=0x0000000000000000 a3=0x0000001997870ca0 a4=0x00000015671925a0 a5=0x00000015671925a0 a6=0x00000000000000ff a7=0x0000000000000100
1623.514 [#0 lld(47:47)]: t0=0xffffffffffffffc0 t1=0x0000000d2adc290c t2=0x00000011109a7bb0 t3=0x00000011108fc85e t4=0x00000011109a7c70 t5=0x0000000000000040 t6=0x0000000000000000
1623.524 [#0 lld(47:47)]: s1=0x0100000000000000 s2=0x0000001567192620 s3=0x00000179c9c7eff4 s4=0x0000000d2c430058 s5=0x0000000000000003 s6=0x0000000d2dcb0a40 s7=0x0000000d00ae11c0 s8=0x0000000df6620040 s9=0x00000015671928e0 s10=0x0000000df66200e8 s11=0x0000000000000002
1623.550 [#0 lld(47:47)]: 0x0000000d2c3a40f8  (?)

1623.559 [#0 lld(47:47)]: Userspace backtrace:
1623.559 [#0 lld(47:47)]: Kernel backtrace:
Kernel + 0x0000000000473956  Kernel::Process::crash(int, AK::Optional<Kernel::RegisterState const&>, bool) +0x1dc
Kernel + 0x0000000000453592  Kernel::handle_crash(Kernel::RegisterState const&, char const*, int, bool) +0x3d8
Kernel + 0x0000000000005d26  Kernel::PageFault::handle(Kernel::RegisterState&) +0x5ec
Kernel + 0x00000000004c263e  trap_handler +0x3d6
Kernel + 0x00000000004d3d76  restore_context_and_sret +0x0
1624.072 [#0 Finalizer Task(5:5)]: Generating coredump for pid: 47
1656.045 CrashDaemon(34): New coredump file: /tmp/coredump/lld_47_1784101952
1659.788 [#0 clang-23(45:45)]: Terminating clang-23(45) due to signal 6
1659.959 [#0 Finalizer Task(5:5)]: SHENANIGANS! Userspace stack points back into kernel memory
1660.059 [#0 Finalizer Task(5:5)]: Backtrace:
0x00000000deadc0de  Kernel::ProcessorBase::switch_context(Kernel::Thread*&, Kernel::Thread*&) + 0x102
0x00000000deadc0de  Kernel::Scheduler::context_switch(Kernel::Thread*) + 0x134
0x00000000deadc0de  Kernel::Scheduler::pick_next() + 0x104
0x00000000deadc0de  Kernel::Scheduler::yield() + 0x80
0x00000000deadc0de  Kernel::Thread::die_if_needed() + 0x188
0x00000000deadc0de  syscall_handler + 0x7d6
0x00000000deadc0de  trap_handler + 0x29a
0x00000000deadc0de  restore_context_and_sret + 0x0
0x0000001b639beb46  /usr/lib/libc.so: .text + 0x2bb46
0x0000000b9e19752c  /usr/local/bin/clang-23: .text + 0xa652c
1660.204 [#0 Finalizer Task(5:5)]: Generating coredump for pid: 45

46_gcc_backtrace.txt
2-45_gcc_backtrace.txt
47_lld_backtrace.txt
console.txt

And tcc seems to be just as unfinished as it is on x86-64.

Host: Debian 13 amd64
Toolchain: GNU

[spholz]

That is a known issue (https://discord.com/channels/830522505605283862/1139481927594803260/1190010896819433574). On RISC-V the default load address that binutils links executables to is significantly lower than on x86-64 and AArch64 (the default address is likely higher for those due to legacy reasons).

For GCC at least, the problem is that GCC isn't PIE, so when we try to load it there it collides with memory allocations that the dynamic loader did. We should likely be smarter about reserving the memory regions that the program will be loaded to. We could maybe reserve those regions in the kernel and make mmap not return addresses there.