Static-musl ipctool segfaults at process startup on pre-2019 kernels (works UPX-wrapped)

[widgetii]

Summary

A static-musl-linked ipctool (current HEAD, any recent revision, any toolchain version of musl tested) segfaults at process startup on cameras running Linux ≤ 3.18.x kernels. Affects anything launching the binary — not just trace. ipctool --version segfaults the same way.

The shipped UPX-wrapped binary works fine on those same cameras: UPX's stub decompresses + jumps to the unpacked entry without going through musl's standard static-PIE startup, side-stepping whatever the underlying issue is. Since the CI release pipeline UPX-packs the artifact, end users don't see this in production.

Reproducer

Target: hi3516cv300 + XiongMai Sofia firmware (kernel 3.18.20, GCC 4.9.4, uClibc, from 2018). Same hardware where ipctool trace was used to capture WDR sensor sequences.

# ipctool                    # raw musl-static build, same revision as the UPX one
Segmentation fault
$ echo $?  # via shell wrapper
139

# ipctool-upx                # UPX-packed build of the same source
---
chip:
  vendor: HiSilicon
  model: 3516CV300
...                          # works

# ipctool-2021               # 2021-era build, uClibc-linked (libuClibc string in binary)
---
chip:
  vendor: HiSilicon
...                          # works

# ipctool-hisiv500           # current HEAD rebuilt with hisi-v500 uClibc toolchain
---
chip:
  vendor: HiSilicon
...                          # works; traces Sofia correctly with V2/V2A decoders

So:

Build	OS/ABI in ELF	Result
static musl (Buildroot 13.3 or xm530 7.5)	UNIX - System V	segfault at entry
static uClibc (hisiv500 4.9 or 2021-era 4.9)	UNIX - System V	works
UPX-wrapped musl	UNIX - GNU	works (stub bypasses normal init)

Root cause

Bisected: builds at 4f87fae (= before #152 / #153 / #155 V2-fix series) segfault the same way. The regression is not in any recent code — it's in the static-musl entry path on old kernels. Likely candidates:

• musl reading AT_RANDOM / AT_HWCAP from auxv that the 2018 kernel doesn't supply
• musl-side static-PIE relocation or vDSO probing
• TLS init expecting auxv entries that Linux 3.18 ARM doesn't pass

I didn't drill into which specific musl init step faults — once the workaround was clear (UPX or uClibc) the build pipeline already handled it.

Why this matters / who's affected

Anyone using ipctool to trace legacy vendor firmwares (XiongMai Sofia, older 2018-era HiSilicon SDK builds) that run on pre-4.x kernels. Modern OpenIPC / Majestic builds are fine because their kernels are 4.9+.

Because release artifacts are UPX-wrapped, this is invisible in normal use. It only bites people who:

• Build ipctool from source for development (./build.sh or similar), and
• Try to use it on a legacy camera.

Suggestion

Document in README / docs/sensor-driver-extraction.md Troubleshooting:

ipctool segfaults at startup on a legacy camera (pre-4.x kernel, e.g. XiongMai Sofia)

The static-musl binary's entry path is incompatible with Linux ≤ 3.18.x. The release artifact is UPX-wrapped which side-steps this — use the published ipctool-upx for tracing legacy firmware, or rebuild against a uClibc toolchain (e.g. arm-hisiv500-linux).

Optionally add a cmake/Toolchains/hisiv500-uclibc.cmake so source builds for legacy targets are a one-flag operation.

References

Surfaced while diagnosing IMX291 WDR — needed runtime ipctool tracing of a Sofia camera in daylight to compare SHS1/SHS2/RHS1 against an OpenIPC build's writes (resolved separately as widgetii/sony_imx291@c4c2d24). Trace itself works once the binary actually starts; the V2 decoders introduced in #152 / #153 / #155 are functioning correctly when run from a uClibc-built or UPX-wrapped binary.