This is a feature that involves both Cortex-Debug and VSCode. Note that all the presentation and user interface are handled by VSCode, while we provide the data to present.
While in a debug session and in a paused state, you can invoke the disassembler and view the disassembly for that source code. This Disassembly
view is provided by Microsoft/VSCode and I would still consider it a work in progress but it has been functional thus far. Cortex-Debug provides the backend and VSCode provides the window/menus that you interact with. Here are the features thus far
CALL STACK
window by right-clicking on any frame of any thread. This will make the Disassembly window appear.
Lock Group
using the ...
menu on the top right. This way when you double click on an assembly instruction, the source will open in the adjacent group.It is difficult to tell if the disassembly is actually accurate.
Known issue: Sometimes you may not see source code when the current instruction is near a bunch of other functions that do not have source. This happens for example if you are stopped in main, and your main is small, and it is surrounded by startup code that does not have source. Not sure why gdb is doing this
Since arbitrary addresses are used to fetch instructions, we may not be getting the correct ones. Especially if the start address is in the middle of an instruction. We try multiple times to make sure that some known instructions are in the right location -- meaning all others will be as well. Please report if you are suspecting inaccurate disassembly. This is more of an issue with CPUs like Xtensa with variable instruction widths. ARM/RISC-V are either 16 or 32 bit which is far more reliable.
The address range may be beyond the limits of memory regions. We try to detect this and display a '??' just before the instruction to indicate that it might be suspicious. In the event that a request to gdb to disassemble fails, we try to reduce the memory to be within the known memory regions and try again. But we still have to satisfy the request from VSCode. You may see something like the following when that occurs (partly in a valid region and partly outside)
You can get the regions defined for your device/target using the gdb command info mem
. If this is empty or wrong then you may see issues with the disassembly not working fully, especially at the boundaries of memory regions.
We are not sure how VSCode deals with multiple memory regions that are disjoint. You can have code in ROM, FLASH, external FLASH, SRAM, and all combinations of those memories. They are generally in disjoint address spaces. We know Cortex-Debug and GDB can handle it but not sure if VSCode can. It should be okay because VSCode also has to deal with native programs where DLLs are typically located in very different address spaces than the main executable. Let us know if you are seeing a problem.. It seems to handle it fine, but please report any issues.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4