Disassembly Debugging

This is an experimental feature for both Cortex-Debug and VSCode and is available in pre-release versions. It is pretty usable and we would appreciate some feedback. Note that all the presentation is done 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

• Trigger Disassembly either from the editor or in the CALL STACK window by right-clicking
  • It can disassemble an entire executable but it will only do it based on how far you scroll. It is more like on-demand disassembly.
  • You can toggle 'Source code' embedding from the Command Palette. Hint: Create a keyboard shortcut
• You can arrange your windows such that the disassembly and source code windows are side by side
• You can single step in either of the windows. If the focus is in the disassembly window, it will do a step/next at an instruction level
• Tip: You can arrange your windows to be in a side-by-side configuration and then invoke Lock Group using the ... menu on top right. This way when you double click on an assembly instruction, the source will open in the other group.
• You can set breakpoints at any instruction just like you do for source files (in the gutter area). The UI to set conditions and hit counts are not yet enabled although our backend supports conditions

Caveats

It is difficult to tell if the disassembly is actually accurate.

• 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.
• 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.

• We have noticed that sometimes, gdb does not produce source file/line information when a large chunk of the memory region start address of the query contains no source information but some does later on in the same region. This is repeatable but not sure what the solution is. Maybe do gdb queries in smaller chunks???