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
- Very specific: line 41
Use the first divergent record, not the last error message, as the starting point.
≈ “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.
Files
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.nvmThe 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.nvmRead 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.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/code-quality/RULE.mdCursor rule
- .cursor/rules/file-organization/RULE.mdCursor rule
- .cursor/rules/testing-standards/RULE.mdCursor rule
- github-issue-trackingSkill
- reading-nanolangSkill
- release-readinessSkill
- releasing-documentationSkill
- releasing-presentationSkill
- releasingSkill
- roadmap-executionSkill
- session-completionSkill
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.

