agentleFS
jordanhubbardjordanhubbard/nanolang/skills/nanovm-opcode-debugging/SKILL.md

nanovm-opcode-debugging

Skill628 starsChanged 4 months agoApache-2.0View on GitHub

Diagnose NanoVM opcode, stack, value, and FFI failures with the optional NANO_VM_TRACE instrumentation.

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use the first divergent record, not the last error message, as the starting point.

    line 41

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

NanoVM Opcode Debugging

I keep opcode tracing disabled by default. Enable it only while diagnosing a specific VM failure; tracing writes one record per retired instruction and can produce substantial output.

Enable tracing

Build the normal VM, then set the environment variable before starting it:

NANO_VM_TRACE=1 ./bin/nano_vm failing.nvm

The VM reads NANO_VM_TRACE once during vm_init. The instruction dispatch path checks only the cached boolean. Any non-empty value other than 0 enables tracing. NANO_VM_TRACE=0 disables it.

To inspect a NanoLang source program through NanoVM:

NANO_VM_TRACE=1 ./bin/nano_virt program.nano --emit-nvm -o /tmp/program.nvm
NANO_VM_TRACE=1 ./bin/nano_vm /tmp/program.nvm

Read the trace

Each record includes the function index, function name, bytecode offset, opcode, stack depth before and after execution, and the top stack values. Heap values include their tag, address, length where applicable, and printable contents. FFI records include the import, C symbol, argument count, return tag, and marshaled result.

Use the first divergent record, not the last error message, as the starting point. For string failures compare the PUSH_STR, FFI return, and equality records. For stack failures compare the stack depth around the first operation whose declared effect differs from the observed effect.

Tracing is diagnostic evidence, not a correctness proof. Reproduce the failure with tracing disabled after the fix and run the relevant NanoVM, NanoVirt, and benchmark quality gates.

Generated C diagnostics

Generated-C timing instrumentation is controlled once at process startup by NANO_PROFILE. When an executable was built with --profile, use NANO_PROFILE=1 to collect timing data or NANO_PROFILE=0 to turn the hooks off without rebuilding. The generated hook checks only its cached boolean on the hot path.

The generated-C toggle is separate from NANO_VM_TRACE. NANO_PROFILE only controls timing and flamegraph data emitted by a --profile build; it does not turn on opcode tracing in NanoVM. Run both variables when a failure crosses the compiler and VM boundary.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.