| 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:45 |
| 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 |
| dramforever | in configure.ac | 03:59:09 |
| Tristan Ross | Also, I noticed there's a --with-riscv option in audit that we can enable lol | 03:59:11 |
| Tristan Ross | Yeah, I'm trying to turn that off | 03:59:24 |
| dramforever | why is this even an option | 03:59:34 |
| Tristan Ross | Idk | 03:59:51 |
| dramforever | maybe it'll work if you turn --with-riscv on? | 04:00:05 |
| Tristan Ross | It didn't | 04:00:10 |
| dramforever | rip | 04:01:01 |
| Tristan Ross | Otherwise, I could just disable the tests for now | 04:01:41 |
| Tristan Ross | It's not like RISC-V is that heavily adopted that loosing out on the check phase would be bad. | 04:02:02 |
| Tristan Ross | And there's the NixOS tests | 04:02:13 |
| dramforever | you can sed it out on isRiscv | 04:02:32 |
| Tristan Ross | Yes | 04:02:38 |
| Tristan Ross | https://github.com/NixOS/nixpkgs/pull/461813 sweet, this worked | 04:13:12 |
| Tristan Ross | I didn't see https://github.com/NixOS/nixpkgs/pull/453516 moved the tests out lol | 04:30:02 |
| dramforever | In reply to @rosscomputerguy:matrix.org
I didn't see https://github.com/NixOS/nixpkgs/pull/453516 moved the tests out lol just add it unconditionally and target staging? | 05:27:34 |
| dramforever | staging is unfrozen now too | 05:27:59 |
| Tristan Ross | Ah | 05:28:04 |
| Tristan Ross | Sure | 05:28:06 |
