| 14 Nov 2025 |
 no-mood | * Hi all, I have a few questions on RISC-V cross-compilation in Nix
I need a bare-metal RISC-V toolchain (riscv32-none-elf with newlib, not Linux).
I'm using pkgs.pkgsCross.riscv32-embedded.buildPackages.gcc which provides the correct riscv32-none-elf-gcc.
Now:
- Is
pkgsCross just syntactic sugar over crossSystem, or are there functional differences?
- For bare-metal embedded: should I use
pkgsCross.riscv32-embedded.buildPackages.gcc
or is there a better package?
For context, I'm writing a SpinalHDL/Verilog project, with RISC-V firmware for an FPGA (no OS, pure embedded)
| 11:49:53 |
| no-mood | * Hi all, I have a few questions on RISC-V cross-compilation in Nix
I need a bare-metal RISC-V toolchain (riscv32-none-elf with newlib, not Linux).
I'm using pkgs.pkgsCross.riscv32-embedded.buildPackages.gcc which provides the correct riscv32-none-elf-gcc. Now:
- Is
pkgsCross just syntactic sugar over crossSystem, or are there functional differences?
- For bare-metal embedded: should I use
pkgsCross.riscv32-embedded.buildPackages.gcc
or is there a better package?
For context, I'm writing a SpinalHDL/Verilog project, with RISC-V firmware for an FPGA (no OS, pure embedded)
| 11:50:02 |
 Alex | Answer to 1: yes. | 11:50:17 |
| Alex | * Answer to 1: yes, it is just sugar (and crossSystem is far more flexible). | 11:50:45 |
 Tristan Ross | FAIL: lookup_test
=================
AddressSanitizer:DEADLYSIGNAL
=================================================================
==12600==ERROR: AddressSanitizer: SEGV on unknown address 0x100d5554fbe8 (pc 0x7ffff7877a26 bp 0x7fffffffdf60 sp 0x7fffffffd710 T-1)
==12600==The signal is caused by a READ memory access.
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12600)
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12600)
FAIL lookup_test (exit status: 133)
FAIL: auparse_extra_test
========================
AddressSanitizer:DEADLYSIGNAL
=================================================================
==12629==ERROR: AddressSanitizer: SEGV on unknown address 0x100d5554fbe8 (pc 0x7ffff7877a26 bp 0x7fffffffdf50 sp 0x7fffffffd700 T-1)
==12629==The signal is caused by a READ memory access.
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12629)
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12629)
FAIL auparse_extra_test (exit status: 133)
Oh no, audit fails to build...
| 19:04:45 |
| Tristan Ross | (This is native btw) | 19:04:52 |
| Tristan Ross | * FAIL: lookup_test
=================
AddressSanitizer:DEADLYSIGNAL
=================================================================
==12600==ERROR: AddressSanitizer: SEGV on unknown address 0x100d5554fbe8 (pc 0x7ffff7877a26 bp 0x7fffffffdf60 sp 0x7fffffffd710 T-1)
==12600==The signal is caused by a READ memory access.
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12600)
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12600)
FAIL lookup_test (exit status: 133)
FAIL: auparse_extra_test
========================
AddressSanitizer:DEADLYSIGNAL
=================================================================
==12629==ERROR: AddressSanitizer: SEGV on unknown address 0x100d5554fbe8 (pc 0x7ffff7877a26 bp 0x7fffffffdf50 sp 0x7fffffffd700 T-1)
==12629==The signal is caused by a READ memory access.
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12629)
AddressSanitizer: CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0) (tid=12629)
FAIL auparse_extra_test (exit status: 133)
Oh no, audit's tests fail...
| 19:05:11 |
| 15 Nov 2025 |
| Tristan Ross | https://github.com/linux-audit/audit-userspace/issues/504#issuecomment-3535532063
Wouldn't the AddressSanitizer: "CHECK failed: asan_suppressions.cpp:47 "((suppression_ctx)) != (0)" (0x0, 0x0)" be an internal assertion failure within ASAN? The suppression_ctx (suppression context) pointer is null when it shouldn't be, causing ASAN to crash while trying to handle a memory error.
Recommend not using ASAN in the build process until it's support is better. Check for compiler issues around ASAN on RISC-V. Let "make check" run without ASAN and see if it passes.
Hmm, how do you even turn off ASAN?
| 03:53:04 |
 dramforever | Tristan Ross: audit unconditionally enables asan if found | 03:58:31 |
| Tristan Ross | Oh | 03:58:43 |
