You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
Just letting you know, that VSC got support for disassembly view microsoft/vscode#124163
So UI should be already solved and not it's up to extensions to provide disassembly feature.
Unfortunately, I am not able to help in any other way than testing.
Yup, tracking that. I was involved in getting disassembly (and registers and memory) into the protocol specification a while ago. It is already included in the July release of VSCode. Now, there is an implementation. Disassembly was less of an issue than doing lazy disassembly, handling breakpoints, stepping, etc. We have something that already works (you can invoke it using the 'Command Pallete') but it is function-based
I am not sure the UI is already solved. We will see what the C++ extension did with this and how far it went.
Reacted by Patrik Bachan, Djordje Nedic, Ivan Zrno, heartacker and yxh
Seems that with the October Release (1.6) they also added interleaved code in the new disassembly view microsoft/vscode#132541 . So this would also address #64.
I already had initially looked/debug into the MI interface on how to get the information from GDB. @haneefdm If you don‘t mind or already working on that, i‘ll give it a try after my planned doc cleanup is finished
Yes, go for it. Please enable TSLint. For some reason, some code you checked in did not pass that. I was part of adding that to the adapter protocol specification.
We are supposed to use ESLint but that migration proved to be a huge amount of work. We have to bite that bullet sooner than later.
Be careful about performance and it needs to be lazy loading of the asm code. Mapping disassembled code to breakpoints is another thing to keep in mind. This could be pretty involved but will be worth it.
Also, if you can, don't assume any type of assembly. Just take whatever gdb gives you. Including RISC-V or 64-bit code. Going forward, I am trying to be agnostic about those things.
Oh, and I think we finished this before MS did for the cpptools. I did provide them with my implementation and the pitfalls with gdb. They were reading the memory three times to do the disassembly, I am doing it in one pass. Knowing valid memory regions is tough on a native file system -- also hard in an embedded system when stuff is stored outside the device and loaded at run-time.
When they are done, I have to go to their implementation to see what I can learn.
Activity
haneefdm commentedon Aug 9, 2021
Yup, tracking that. I was involved in getting disassembly (and registers and memory) into the protocol specification a while ago. It is already included in the July release of VSCode. Now, there is an implementation. Disassembly was less of an issue than doing lazy disassembly, handling breakpoints, stepping, etc. We have something that already works (you can invoke it using the 'Command Pallete') but it is function-based
I am not sure the UI is already solved. We will see what the C++ extension did with this and how far it went.
Trass3r commentedon Aug 19, 2021
microsoft/vscode#129762 is the next stage.
PhilippHaefele commentedon Nov 21, 2021
Seems that with the October Release (1.6) they also added interleaved code in the new disassembly view microsoft/vscode#132541 . So this would also address #64.
I already had initially looked/debug into the MI interface on how to get the information from GDB. @haneefdm If you don‘t mind or already working on that, i‘ll give it a try after my planned doc cleanup is finished
haneefdm commentedon Nov 21, 2021
Yes, go for it. Please enable TSLint. For some reason, some code you checked in did not pass that. I was part of adding that to the adapter protocol specification.
We are supposed to use ESLint but that migration proved to be a huge amount of work. We have to bite that bullet sooner than later.
Be careful about performance and it needs to be lazy loading of the asm code. Mapping disassembled code to breakpoints is another thing to keep in mind. This could be pretty involved but will be worth it.
Also, if you can, don't assume any type of assembly. Just take whatever gdb gives you. Including RISC-V or 64-bit code. Going forward, I am trying to be agnostic about those things.
haneefdm commentedon Nov 21, 2021
Btw, the MI interface is the easy part. It is the presentation.
PhilippHaefele commentedon Jan 5, 2022
Thanks to @haneefdm the extension has now (since prerelease version V1.1.7) support for the VSCode Disassembly view
PhilippHaefele commentedon Jan 20, 2022
@haneefdm 🥳
haneefdm commentedon Jan 20, 2022
Hi @PhilippHaefele , not sure if you noticed in the release notes...
This was a pretty large release. Fingers crossed. Thank you so much. On to WSL support (and Docker/SSH)
haneefdm commentedon Jan 20, 2022
Oh, and I think we finished this before MS did for the cpptools. I did provide them with my implementation and the pitfalls with gdb. They were reading the memory three times to do the disassembly, I am doing it in one pass. Knowing valid memory regions is tough on a native file system -- also hard in an embedded system when stuff is stored outside the device and loaded at run-time.
When they are done, I have to go to their implementation to see what I can learn.
PhilippHaefele commentedon Jan 20, 2022
Thank you very much for this mentioning. Also thank you very much for this great release. Me and my colleagues will enjoy the new features.
Hope i get some free time soon to finish my documentation work.