VSCode plugin for MIR textual format

[eliphatfs]

I'm working on a JIT compiler these days and I usually end up in reading my MIR emission in the textual format for debugging. Thus I made a VSCode plugin (basically a syntax highlighter and same-token-as-selection highlighter currently) for reading MIR textual format more easily. Hope that it would be useful.
https://marketplace.visualstudio.com/items?itemName=eliphatfs0.vscode-mir

[vnmakarov]

This is cool. I am not familiar with VSCode but I know it is very popular. So thank you for implementing it and sharing it.

I am planning to improve development experience for MIR. So what you are doing could be part of this. From my side I'd like to implement debugging MIR generated code in gdb on MIR level and C level when MIR is generated by c2m but it is a big project. I guess this could be also integrated into VSCode plugin.

[rofl0r]

ftr, tinycc uses stabs format for debugging, which seems to be a whole lot easier to implement than dwarf.

[vnmakarov]

I have no previous experience in doing so, but it seems that every debugging format has a line number table, so perhaps tracking the lines from MIR or C would be a good point to start?

Yes. It could be a start. Next could be variable placement (in what area of code, register of stack slot). But the very first thing should be a design of the format, it represenation in MIR and how to use it.

[vnmakarov]

ftr, tinycc uses stabs format for debugging, which seems to be a whole lot easier to implement than dwarf.

Stabs are old and outdated.

People starting to learn dwarf could be overwhelmed as its specification is huge. But we need just very small subset of it.

I think ctf could be used too. GDB/GCC/binutils now has support for it (https://linuxplumbersconf.org/event/11/contributions/1003/) and its specification is less than 30 pages.

[eliphatfs]

In the near future I am planning to try directly implementing the debugger adapter protocol in the MIR interpreter, with small modifications in the scanner to track line numbers. The protocol is recognized by plugins in vim, emacs, vscode and many other editors. Perhaps this will be inconsistent with your design, but I think it is currently enough for me to debug my JIT front-end, and also it is easy to implement -- End users like me would expect generated code work the same as the interpreter, and if not they would file an issue, so I do not bother emitting information in generated objects; I just debug MIR text with the interpreter.

[eliphatfs]

I'm working on it! https://github.com/eliphatfs/mir/tree/dap-intp

[eliphatfs]

Simple one-file MIR can be run with interpreter from VSCode now, and the next step is stopping and inspecting. MIR interpreter cleverly utilizes the host call stack by unifying self-call with FFI and thus does not track the stack info. Need to add that.

[eliphatfs]

Stepping through!

[eliphatfs]

Almost finished the first steps for a debugger -- Breakpoints. Stepping in/over/out. Stack trace. Interactively viewing variables in each stack frame. Hovering inspection of variables. Basic REPL (s var val for setting and p type val for printing variables).

I'm going to take a rest, and then going on testing on multiple platforms. Some parts of code are messy and lack a universal design, which will be changed later.