Debugger: disassembly view in VS.Code not updating properly #4904
Labels
bug
Something isn't working
Comments
This was referenced Apr 24, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
May 22, 2024
…4941) # Description ## Problem\* Resolves #4904 The disassembly view from VS.Code didn't work properly. Sometimes it would only show the first opcode only and once open it wouldn't update the current opcode pointer when stepping through the code. This was because we were using opcode locations (eg. `3.17`) as instruction references (typed as string in the API), but VS.Code expects integers either in decimal or hexadecimal format. ## Summary\* This PR updates the disassembly request DAP command handler to return integer addresses only, and changes the instruction set breakpoint command to parse and map the given address to the appropriate opcode location. ## Additional Context ## Documentation\* Check one: - [X] No documentation needed. - [ ] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [X] I have tested the changes locally. - [X] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Aim
When using the debugger in DAP mode from VS.Code, opening the disassembly view sometimes shows incomplete opcodes (esp. after applying #4897) and stepping through the code does not update the pointer to the currently executing opcode.
Expected Behavior
The view should display all opcodes in the program being debugged and update properly when issuing the step commands.
Bug
I think this may be related to the way we're rendering the memory addresses for each opcode. In DAP, memory addresses are strings from which one would assume they can be any arbitrary string. We're currently using that assumption to render opcode locations inside Brillig and BrilligCall opcodes as
3.17(meaning index 3 on ACIR, 17 on Brillig). The DAP specification is very sparse, but it does mention that it should be treated as an hex value with the0xprefix, or as a decimal value otherwise.To Reproduce
Project Impact
None
Impact Context
No response
Workaround
None
Workaround Description
No response
Additional Context
No response
Installation Method
Compiled from source
Nargo Version
nargo version = 0.27.0 noirc version = 0.27.0+1969ce39378f633e88adedf43b747724b89ed7d7
NoirJS Version
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response
The text was updated successfully, but these errors were encountered: