Appendix — Recovered Source-File Path Glossary

Every path, address, and binary on this page applies to neuronx_cc 2.24.5133.0+58f8de22 (cp310 wheel; the IDA string dumps backing this page are the cp310 set, so the build root is uniformly …KaenaCompilerNativeBuild-310/…/src-3.10.16/…). cp311/cp312 carry byte-near-identical twins that renumber addresses and substitute the -311/-312 build root. Other versions will differ.

Abstract

The shipped neuronx-cc binaries were compiled with assert(...) left in. Each surviving assert expansion plants its __FILE__ argument — the compiler's own source-file path — as an interned string in .rodata, frequently followed by a :lineno suffix from the __LINE__ macro. This appendix is the glossary of those recovered path strings: it takes every neuronxcc-internal source-file literal found in the binaries' string tables and maps it to the subsystem it implements and the wiki page that documents that subsystem.

These strings are direct binary evidence of internal structure. A path like walrus/coloring_allocator/src/sb_allocator/sb_spill.cpp is not a guess about how the allocator is organized — it is the literal byte sequence the compiler emits when an assertion in its spill code fires, recovered from the .rodata of libwalrus.so. The path is the module boundary, the directory is the subsystem decomposition, and the :lineno suffix pins the assertion to a line. Where a normative page says "the SBUF allocator's spill phase", this appendix shows the file that phase lives in. The provenance model behind treating these as ground truth — and the firewall that keeps this wiki derived solely from binary analysis — is §0.3 Methodology.

The glossary is curated by relevance, not exhaustive. The cp310 dumps carry 309 distinct neuronxcc-internal source paths (plus thousands of vendored external/com_google_absl/…, protobuf, re2, onednn paths that are not neuronx-cc source and are excluded here). This page reproduces the compiler-source paths a reader will actually want to resolve — the IR core, the backend passes, the allocators, the codegen, the simulator, the dtype support, the generators — grouped by the subsystem prefix that is the path's own first directory. §1 explains how the strings are planted and how to re-extract them; §2–§9 are the per-subsystem tables; §10 re-confirms five literals byte-for-byte against the cited binary's _strings.json.

NOTE — every path quoted below is reproduced verbatim from a binary string table, stripped only of the constant build-root prefix and any :lineno suffix for readability. The full literal (with prefix and line) is what appears in the binary; §10 shows three of them in full. These are the compiler's own embedded paths — they are not sourced from any external, leaked, or reconstructed source tree, and nothing on this page describes source the project did not ship in the binary.

1. How the paths got into the binary

A path string reaches .rodata through one of three mechanisms, all of them ordinary C/C++ build artifacts that a stripped binary still carries:

(1) assert(cond)  →  __assert_fail("cond", __FILE__, __LINE__, __func__)
        the libc assert macro interns __FILE__ as a string operand of the
        __assert_fail call. Surviving asserts ⇒ the full source path is in .rodata,
        usually as "<path>" and a separate ":<lineno>" or "<path>:<lineno>".

(2) custom check/throw macros  →  log("<file>:<line> <expr>")
        e.g. libbuiltincustomop's sort_and_merge.cpp asserts surface as ONE string
        "sort_and_merge.cpp:122 right_data_buffer != nullptr && ..." — file, line,
        and the failed predicate concatenated (category "generic", not "path").

(3) generator provenance banners  →  literal "Generated by brewer from … brewer.py …"
        the instabrew generator stamps each emitted *OpGen module with a banner
        naming its own generator source — brewer.py — and the .pyx it came from.

The IDA string-dump pipeline classifies each literal; neuronxcc source paths land in "category": "path" (mechanisms 1 and 3 with a full build-root prefix) or "category": "generic" (mechanism 2, the concatenated file:line predicate form). Both are recovered by the same sweep.

Re-extracting the glossary

  # all neuronxcc-internal source paths, any binary, strip build-root + :lineno
  for f in ida/*/*_strings.json; do
    jq -r '.[].value | select(test("src-3\\.10\\.16/neuronxcc/")) |
           select(test("\\.(cpp|cc|hpp|h|py|pyx)"))' "$f"
  done | sed 's#.*/neuronxcc/##; s/:[0-9].*$//' | sort -u
  #   => 309 distinct paths (the rows below)
  # the build root is uniform across the cp310 dumps:
  #   /opt/workspace/KaenaCompilerNativeBuild-310/build/private/src-3.10.16/neuronxcc/

GOTCHA — the dumps also carry thousands of external/com_google_absl/…, external/com_google_protobuf/…, external/com_googlesource_code_re2/…, and external/onednn/… paths. Those are statically-linked third-party sources (Abseil, protobuf, RE2, oneDNN), not neuronx-cc code, and are excluded from every table here. The discriminator is the …/src-3.10.16/neuronxcc/ prefix versus …/external/. Only the neuronxcc/ subtree is the compiler's own source.

2. The six anchor paths

These six are the brief's worked examples and the highest-value entries — each names a distinct subsystem and resolves to a documented page. All are reproduced verbatim from the cited binary's _strings.json (category: path, except the custom-op asserts which are generic).

NOTE — float_converter.cpp and brewer.py appear in three binaries each. That is expected and itself evidentiary: bir/pelican/dtype support is shared code statically pulled into libBIR, libBIRSimulator, and krtlib (see Symbol & Offset Index §0.1). The same __FILE__ literal in multiple binaries confirms the same translation unit was linked into each. loop_profitable_fusion.cpp appears both in libwalrus.so and as its own standalone loop_optimization pass-driver ELF — the pass ships both ways.

QUIRK — sort_and_merge.cpp is the only anchor with no build-root prefix: the custom-op .so files use a bespoke check macro (mechanism 2) that interns just the basename plus the line and the failed predicate, e.g. sort_and_merge.cpp:618 right_start < dim2. The eight libbuiltincustomop_cpu0..7 copies are byte-identical bodies relocated per-core (0x8407…/0x8427…/…), so the same 17 assert strings recur eight times.

3. walrus/ir/ — the BIR IR core (libwalrus.so)

The walrus/ir/ subtree is the BIR in-memory IR: instruction/block/function objects, access patterns, the affine machinery, and the embedded simulator. These are the densest assert sites; the table is grouped by leaf, representative not exhaustive.

4. walrus/coloring_allocator/ — the register/SBUF/PSUM/DRAM allocator (libwalrus.so)

The allocator is a graph-coloring core specialized per memory space; the path tree is the per-space decomposition (each space gets a build/select/spill/simplify/live_range quintet). The *_with_loop variants live in their own coloring_allocator_with_loop ELF.

5. walrus/ backend passes (libwalrus.so + per-pass split ELFs)

Each pass directory is a walrus/<pass>/src/<pass>.cpp. The pass-name is the pass purpose; the registry that drives them is walrus/registration/src/backend_pass_manager.cpp. Representative high-traffic passes:

6. walrus/codegen/ — the descriptor / core-generation codegen (libwalrus.so)

NOTE — the CoreV2/V3/V4GenImpl triple is the binary's own evidence for the three live core generations. The hwm/ hardware-model files in §8 (cayman_bir.cpp, sunda_bir.cpp, core_v4_bir.cpp) are the matching per-codename device models. Cross-check against Codename Taxonomy and Vestigial Generations.

7. pelican/ — the affine-index / expression IR (libBIR.so)

pelican is the affine-expression / value IR underneath BIR (owned by libBIR.so, §0.1). Its include/pelican/IR/*.h and lib/IR/*.cpp literals appear in libBIR.so's string table.

8. hwm/, support/ — per-hardware models and shared cores

9. Cython-origin .pyx and .py paths

The neuronxcc-internal Python-origin paths are few — most of the frontend is interpreted .py not compiled, so only the Cython-compiled modules plant their .pyx/.py source into a binary. The *OpGen.cpython-310-…so encoder modules are themselves brewer-generated C from those .pyx; each carries a provenance banner naming brewer.py.

NOTE — the *OpGen module names in the dump (MatMulOpGen, TensorScalarPtrOpGen.cpytho_…, TiledSoftmaxOpGen.cpyth_…, …) are module/symbol names, not source paths — they are the outputs brewer emitted, each tagged with the brewer.py:3384 banner. The single source-of-truth .py path is instabrew/brewer.py; the :3384 is the emit-site line inside brewer's template engine. This is the binary's own confirmation of the *OpGen-from-brewer contract documented in §7.10.

10. Adversarial verification — five paths re-confirmed

Five literals were re-extracted directly from the cited binary's _strings.json to confirm the byte-exact string is present (not paraphrased). Command form:

jq -r '.[] | select(.value|test("<path>")) | "\(.addr)\t\(.category)\t\(.value)"' \
  ida/<binary>__…_strings.json

NOTE — the category field is itself a provenance signal: neff_packager/perf_sim/float_converter/loop_profitable_fusion all carry "category": "path" (full build-root __FILE__ literals), while sort_and_merge's carry "category": "generic" (the concatenated file:line predicate custom-check form). Both are binary-resident; neither is reconstructed. brewer.py's three hits also carry "category": "path".

Cross-References

• Methodology & the Confidence Model — §0.3; the provenance model that makes these __FILE__ literals citable ground truth and the firewall keeping the wiki derived solely from binary analysis.
• brewer.py Generator & the *OpGen Contract — §7.10; the instabrew/brewer.py generator whose path and :3384 banner this glossary recovers.
• perf_sim Wiring & the pttf Trace Tarball — §8.46; the walrus/perf_sim/src/perf_sim.cpp subsystem this glossary maps.
• Symbol & Offset Index — the address→page reverse lookup; pair a recovered path here with its symbols there.
• Error-Message Catalog — the assert messages (the predicate text) whose __FILE__ paths this page catalogs.
• The Pass Catalog — the walrus/<pass>/src/<pass>.cpp paths resolved to pass objects and registry order.