Skip to content

[ImportVerilog] Thread $stacktrace caller context#10639

Closed
AmurG wants to merge 1 commit into
llvm:mainfrom
AmurG:port-stacktrace-main
Closed

[ImportVerilog] Thread $stacktrace caller context#10639
AmurG wants to merge 1 commit into
llvm:mainfrom
AmurG:port-stacktrace-main

Conversation

@AmurG

@AmurG AmurG commented Jun 12, 2026

Copy link
Copy Markdown
Contributor

Lower the $stacktrace system task by threading a hidden caller-location argument through to the called subroutine, so the stack trace reflects the SV call site. The caller context is recovered during import and passed as a synthesized argument.

Part of a series upstreaming SystemVerilog/UVM simulation support validated against the sv-tests suite.

🤖 Generated with Claude Code

Lower the `$stacktrace` system task by threading a hidden caller-location
string argument into every subroutine that can reach a `$stacktrace` call,
directly or transitively. The task prints a stack trace assembled from the
subroutines currently being lowered plus the threaded caller frames.
@circt-bot

circt-bot Bot commented Jun 12, 2026

Copy link
Copy Markdown

Results of circt-tests run for a97f83f compared to results for e003d2c: no change to test results.

@AmurG

AmurG commented Jun 16, 2026

Copy link
Copy Markdown
Contributor Author

@fabianschuiki — this is a small, self-contained ImportVerilog change (CI green) with no reviewer assigned yet. Could you take a look, or point me to the right reviewer, when you have a cycle? Thanks.

@fabianschuiki fabianschuiki left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's quite a bit of code here to plumb stacktrace formatting through procedure lowering. Having this mixture of a stacktraceCallerStack, currentSubroutineStack, and a stacktraceCallerArgState feels extremely brittle and hard to maintain. How about we isolate the stacktrace threading logic into a separate Moore dialect pass, for example MaterializeStackTraces? We could have ImportVerilog emit a moore.builtin.stacktrace op, and then use MLIR's call graph infrastructure and DFS traversal (or a custom worklist) to figure out which subgraphs of the call graph need the parent's stack frame information. A second step of the pass could then thread the parent's stack context down into the caller. That would also make the stack trace accurately reflect what we end up having in the IR. WDYT?

@AmurG

AmurG commented Jun 18, 2026

Copy link
Copy Markdown
Contributor Author

Full disclosure: AI generated text, via a human in CLI.

@fabianschuiki — small, self-contained ImportVerilog $stacktrace fix, CI green and no dependencies. A review whenever you have spare bandwidth would be appreciated — no rush, and definitely lower priority than the sim-runtime work on #10642.

@AmurG

AmurG commented Jul 8, 2026

Copy link
Copy Markdown
Contributor Author

Closing (same reset as #10697), and answering the design question I left hanging: you were right, the MaterializeStackTraces Moore pass is the better shape. Threading stacktraceCallerStack and friends through the importer is exactly the cross-cutting bookkeeping it shouldn't carry; a pass emitting moore.builtin.stacktrace plus a call-graph walk is testable in isolation. When this returns it returns in that shape, as a fresh PR. Sorry for the three-week silence.

@AmurG AmurG closed this Jul 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants