Feature Request: Refined Disassembly View

[john5f35]

Vadim's LLDB debugger extention has good assembly view.

It would be great if we can add this to this plugin as well.

[Marus]

I will take a look at this; while I think a disassembly view would be a great addition, it isn't as high of a priority for me as some of the other functionality I want to complete. Will definitely keep it in mind for a future addition.

[john5f35]

That's alright. I'm pretty keen putting some work into it my self. I guess I will make a pull request to you when I'm done? :)

[Marus]

I'm certainly more than happy to look at a pull request for what you implement.

[Marus]

While originally I had stated this wasn't a high priority for me, I was having a bit of a restless night last night so I went ahead and implemented most of the functionality for this - you can see it in the v0.1.10-pre release I've pushed to GitHub.

While the majority of this functionality is present - and seems to be working (at least for C, I haven't tested with C++ code yet if you are using any C++; I have a feeling my Symbol Table parsing will be incomplete for C++ - which could effect this and the static/global variable scopes). Here are the things that I see as incomplete with this:

• You are currently unable to set breakpoints in the disassembly view (it will of course still respect the breakpoints set in the source code)
• If you are in an automatic disassembly view (couldn't find the source) it will still try to step by source line instead of instruction (in forced mode it does step instruction-by-instruction).
• There is currently no syntax highlighting for the disassembly view.

I don't expect I will complete those bits before the public v0.1.10 release - but the groundwork will be in place and I expect those enhancements will follow shortly afterwards.

Also out of curiosity - what OS are you using VS Code on? Just good to know what setups other people are testing the extension on.

[Marus]

Actually - you should try the v0.1.10-pre2 release.

This adds basic syntax highlighting for the disassembly view, as well as the ability to set breakpoints in the disassembly view (also fixes some bugs in regards to setting breakpoints in general that I inherited from the extension I based things on originally; would clear out breakpoints in other files when it shouldn't).

Still steps by line not instruction in the automatic disassembly view if you encounter that.

[Marus]

Ok - so one more build for you to try out (hopefully you haven't wasted time with the previous two) - there is a v0.1.10-pre3 now.

This has two changes from pre2:

• This fixes an issue with the symbol table parsing - didn't always find functions properly if there were weak symbols (and people often use a weak alias for default interrupt handlers, overriding with the real implementation - so could run into glitches if you ended up in an interrupt handler without the source for it - or in forced disassembly mode)
• Properly switches to instruction level stepping when in automatic disassembly mode.

[Marus]

And one more question for you about your setup. Just wondering what development board(s) you are using (assuming that they are pre-existing commercial ones). If you run into issues with things it may be useful for you to be able to send example projects for me to test/debug against - so may be useful to have a compatible board if it isn't anything expensive.

Guessing it is based upon the STM32L4 series (since you added a SVD mapping there) - but don't know which one exactly or what board.

[john5f35]

Great work Marus! Those are definitely exciting features. 👍 Unfortunately I haven't gotten around testing them. We will be using this plugin for our university course coming up. It will be on STM32L476 Discovery board, and people will be using it across Windows, Linux and macOS. We will be mainly writing ARM assembly code.

[Marus]

If you do get a chance to test the preview release on GitHub let me know; I’m going to try to get to testing more thoroughly so I can prepare a public release (hopefully tomorrow). Particularly testing it across platforms. I do the main development on OS X, but have been trying to ensure all the important features are working properly (there may be a few features that won’t end up being available on Windows, but nothing that should impact you).

I don’t think I have the L4 discovery board (I do have a fair number of ST boards, covering the F0, F1, F3, F4, F7 and L1 lines; but don’t think I have either L4 part). Developing in assembly is interesting; don’t see many people doing predominantly assembly for larger 32-bit micros. Is there a website for the course? Just might be interesting to see what types of things you are doing.

And if you have any more ideas for features feel free to post them.

[john5f35]

It's a computer architecture course: https://cs.anu.edu.au/courses/comp2300/

[john5f35]

Again, great work so far!

I'm just doing some small testing on v0.1.10-pre3. There seems to be a few problems:

It's an edge case, but I was debugging my program but did not realise that a another different program was running on the board. So when I paused after running the code for a while it fails to identity the function name. This caused an exception to be thrown at gdb.ts:354, being unable to find function named "??". This edge case exception should be caught and dealt with gracefully, maybe displaying an error message to the user?

Another is that the disassembly view for assembly doesn't seem to be working. I tried to disassemble my main function (written in assembly), and it show me an empty document.

Other than that, the disassembly view looks very nice, very much like the LLDB one. Did you borrow ideas from there?

I also have an idea about memory view. I was thinking about add stuff from the Hexdump extension. It's quite powerful. It would also be interesting to make memory view live. Should I open a feature request for that?

[Marus]

Thanks for having a look.

Will look into better handling for the cases you described; Can you send me the output from running "arm-none-eabi-objdump --syms " so I can try to determine why you are not getting any disassembly for your case. I expect when you're building from assembly it doesn't determine the length of the function properly - so not able to determine what part of the program to generate the disassembly from.

I did largely base the ideas off of the LLDB one you pointed out; and used their syntax highlighting as a basis for the one in this extension.

Regarding the ideas for the memory view feel free to make another issue with your suggestions; I will certainly evaluate how good of a fit I think they are and the feasibility.

[john5f35]

I think you might be right. The length of the function is a bit off:

$ arm-none-eabi-objdump --syms firmware.elf
...
0800128c  w    F .text  00000004 MemManage_Handler
080001dc g     F .text  00000000 main
0800128c  w    F .text  00000004 CAN1_TX_IRQHandler
...

The assembly I wrote is quite simple:

.globl   main
.p2align 2
.type    main,%function

main:
    .fnstart
    add      r0, r0, r1
    bx       lr
    .fnend

I'm also just a beginner in assembly programming.

[john5f35]

Also, the debug config snippet for ST-Util has a stutilpath in it that's not supposed to.

[Marus]

Yeah, that’s what I expected was happening; not sure why it is unable to determine the length mind you, but like yourself I’m not an expert in ARM assembly programming (did some x86 and HC11 assembly back in my university days, but don’t remember much of it now).

Can you post the full symbols output (maybe to pastebin, as it will be quite long); maybe I can come up with some way to guess at the appropriate length when the symbol table doesn’t have it.

[Marus]

Also can you try including the -g flag on your arm-none-eabi-as command when you assemble if it is not already there and see what the difference in output is; don't know if the assembler includes debug symbols or not by default.

[john5f35]

I'd say don't worry about the function length now. It's clearly my own issue. Your disassembly view works well with other functions. :)

However I can't seem to add break points in the disassembly view. In some debug stepping it's trying to send an MI command like:

"break-insert "disassembly:/SystemInit.cdasm?function%3DSystemInit:1""

And it got the reply with error, saying "no source file named disassembly". This is v0.1.10-pre3 tag.

[Marus]

Ok - just uploaded a v0.1.10-pre4 release to GitHub that I think will fix the issue with setting breakpoints you encountered.

There is some strange behaviour with VS Code here - it passes the URLs for the disassembly view to the breakpoint request differently when it is an automatically opened disassembly view (either Force Disassembly mode set through the command palette - or can't find the source file) compared to when you manually open a disassembly view through the command palette.

Just had to make some tweaks to the parsing of the URLs so my processing to handle this strange case (it removes the two // from the protocol and URL encodes things when coming from a manually opened view - do not know why).

[john5f35]

Now it did stop at the right instruction. But since I have the source code for the function SystemInit, the line highlight is at the source code, and the stepping is done according to the C source line rather than the disassembly I manually opened. Is there a way to choose which level of stepping it is (maybe by the active document)?

[Marus]

Unfortunately the Debugger process isn’t aware of the document you are viewing. If you wish to step through in the disassembly I would suggest setting force disassembly mode in the command palette. Once you set that then the next step will automatically switch you to a disassembly view and single instruction stepping.

[john5f35]

But it should be possible with some additional logic in the step request, right? Can we get the active document information from VSCode somehow?

[Marus]

For this current release I'm not going to look into it -as I want to get all the features and fixes that are prepared out. I will look into it and see if there is a good way for me to detect the currently active editor and pass that information on to the debugger so it can decide what best to do.

For the time being if you want to step through in the disassembly I would suggest enabling the "force disassembly" mode through the command palette.

[john5f35]

Sure. Thanks!

[Marus]

I've release v0.1.11 - and made tweaks so that stepping mode will reflect the file you are currently focused on (if it is for the current frame) - doing instruction level stepping if you are viewing the disassembly for the current function being executed. (it will also update your views immediately when you switch between forced and automatic disassembly mode, instead of after taking the first step).

[john5f35]

Great work! Thanks Marus! 👍