toolchain-asan: offer hisilicon-hi3516ev200, proven on an ev300

[widgetii]

The stock OpenIPC musl toolchains carry no sanitizer runtime, so scripts/asan.sh in the majestic repo stops at "no libasan.so.* in the hi3516ev200 toolchain sysroot" on every HiSilicon V4 board — which is most of the fleet. Building one locally works; this entry is what saves everyone else from doing it.

Proven, not merely built

The comment above the choice list asks for end-to-end proof on real hardware before a family is listed, so:

• make BOARD=hi3516ev300_lite toolchain-asan
• general/scripts/verify-asan-toolchain.sh — 9 libsanitizer patches applied for gcc 13.3.0, libasan.so.8 present at 1 001 712 bytes, the compiler links -fsanitize=address
• scripts/asan.sh smoke (majestic) against a lab hi3516ev300-imx335:

SMOKE PASSED — on hi3516ev200 AddressSanitizer catches out-of-bounds
reads and writes, LeakSanitizer is live, and suspended threads are read correctly

All three planted controls are reported — out-of-bounds read, out-of-bounds write, and an 81-byte leak — symbolised to file and line on the target with no symbolizer installed there. The suspended-thread check matters because that is the mips failure mode the harness exists to catch.

musl's libasan is smaller than glibc's (1 001 712 vs 1 366 764 bytes); the extra cost is libstdc++.so.6, which a musl rootfs does not ship and deploy sends automatically.

The ev300 defconfig is not a typo

V4 boards share one toolchain and make toolname names it after the family, so hi3516ev300_lite yields toolchain.hisilicon-hi3516ev200. The existing guard in this job (test "${NAME}" = "toolchain.${{inputs.family}}") is what would catch that if it ever stopped holding; a comment says so at the mapping.

One trap for anyone building this by hand

A host GCC 16 cannot build gcc 13.3.0. Its C++ default of 202002L breaks libcody/client.cc on u8"" being const char8_t*, and pinning HOST_CXXFLAGS="-O2 -std=gnu++17" to fix that trips libcody's own configure probe, which compiles #if __cplusplus > 201103 / #error and demands the opposite. Buildroot also strips -std= out of HOST_CXXFLAGS on purpose (filter-out -std=% in package/Makefile.in), so a -std= in HOST_CFLAGS never reaches C++ anyway.

Build it with HOSTCC=gcc-11 HOSTCXX=g++-11 — which is what this runner has, so it is matching CI rather than working around it. Nothing about the resulting toolchain differs. The detail is recorded in majestic's docs/asan.md beside the rest of the recipe.

Not included

hi3516av100 shares the stock toolchain.hisilicon-hi3516ev200 and would share this one, but gets no entry: the list records the board smoke ran on, and borrowing a sibling's proof is the one thing it is there to prevent.

After merge

The artefact still has to be published — dispatch this workflow with family: hisilicon-hi3516ev200. The companion majestic change (the DL_ASAN line, the docs table row and the host-compiler note) is on asan/hi3516ev200 there and should land alongside.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Enable HiSilicon V4 ASan toolchain builds

✨ Enhancement ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Adds HiSilicon hi3516ev200 as a dispatchable ASan toolchain family.
• Maps the shared V4 family to the proven hi3516ev300_lite defconfig.
• Retains the toolname guard to prevent misnamed release artifacts.

Diagram

graph TD
  A["Manual dispatch"] --> B{"Family choice"} -->|HiSilicon V4| C["EV300 defconfig"] --> D["Toolname guard"] --> E["ASan toolchain"] --> F["Artifact verification"] --> G["Release upload"]

Loading

High-Level Assessment

The current approach is appropriate because it follows the workflow's existing family-to-defconfig mapping and retains the artifact-name invariant. Using a board-level workflow input would expose implementation details and risk duplicate family artifacts, while introducing a separate mapping file would add unnecessary complexity for two supported families.

Files changed (1) +5 / -0

Other (1) +5 / -0

toolchain-asan.ymlAdd HiSilicon V4 to ASan toolchain dispatch +5/-0

Add HiSilicon V4 to ASan toolchain dispatch

• Adds 'hisilicon-hi3516ev200' to the hardware-proven workflow choices and maps it to 'hi3516ev300_lite', whose shared V4 configuration produces the expected family toolchain. Comments document the intentional family/board name difference and the existing guard that detects mapping drift.

.github/workflows/toolchain-asan.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗