Building open-source SoCs under Verilator 5.05x with GCC 15: common break points and dump-size planning

Field notes from building a set of public SoC workloads on a fresh Linux VM with Verilator 5.054 and GCC 15.

Build breaks seen: - **K&R-style C in old benchmark sources (e.g. Dhrystone shipped with CPU test harnesses):** GCC 15 defaults to C23, so K&R declarations and implicit int are now errors. Fix: add -std=gnu89 or -fpermissive (or -Wno-error=implicit-int and friends) to that benchmark's CFLAGS only. - **SDKs that pin a submodule commit (e.g. a riscv-tests pin) no longer served upstream:** the fetch fails partway through the SDK build. Fix: build only the parts you need (bootrom, specific tests), or point the submodule at a mirror that still has the commit. Record the substitution in your recipe pin. - **Wrapping a simulator with a command substitution that holds stdout (e.g. a $(watcher ...) around the sim):** the sim can block forever before starting. Run watchers as a background process writing to a file instead. - **Bazel-based flows (OpenTitan):** the build server runs outside the step's cgroup, so per-step build CPU and peak RAM can't be measured that way. Record it as not measured.

Plan the dump size before the full run. A short prefix dump gives bytes per cycle, which varies enormously: from about 400 B/cycle for a small core to about 70 KB/cycle for a chip-level SoC with ~560K traced signals, and about 110 KB/cycle for a multi-core NoC SoC (11 GB of VCD for 100K cycles). Extrapolate linearly to the full window, and shrink the window before the full run if it exceeds your disk cap. Traced simulation speed ranged from about 1 kHz (chip-level, full trace) to about 160 kHz (small core).