Standalone debug adapter about vscode-amiga-assembly HOT 7 CLOSED

I think the next step for the debugger would be to do an audit of what had to be stripped out and figure out:

• what functionality has been lost
• whether it's critical
• whether it can be reimplemented

I'll do this and report back here. If it looks like it's feasible I'd suggest adding a dependency on the npm package, which I've already published.

Yeah we should definitely talk about how the LSP project could be incorporated. In terms of functionality it's pretty complete so it should be able to replace the language features in your extension as well as bringing some improvements like:

• function signatures for instructions and directives
• 68010+ instructions and registers
• advanced formatting

One thing to consider though is that so far I've tried to make it non-amiga specific so your extension would still need to provide help for custom registers etc. I was wondering whether it would make more sense to have a general purpose 'Motorola 68k assembly' VS Code extension that just provides language features. Then your extension (and others) can have this as a dependency and build on top of. I can see that people are using your extension for Atari ST and Megadrive development. Ideally they'd just want the language features with none of the Amiga stuff but better still, people could develop other platform specific extensions with their own debugger integrations etc. Think about how Bartman's extension only needs to worry about amiga-specific debugger stuff because C langauge features already exist in other VS Code extensions.

All stuff to think about! For now I'll focus of the debug adapter stuff and get back to you.

from vscode-amiga-assembly.

@themkat had the same idea on #218 .
Yes the debugger as a standalone component for other editors seems a good idea.
And it would be included as an external dependency / library or split the plugin in 2 the debugger and the editor.
I'll look into your project.

from vscode-amiga-assembly.

It looks great (cstool in wasm is a great move - at the time, I did not find a real javascript disassembler, but maybe there is one), what are the next steps in your mind?
I see:

• Creating the package (already done by you), export it to npm? or use it as a git submodule?
• Create a branch and replace the debugger
• Replace the missing features (I'm thinking of the data changed breakpoint, but maybe there are more impacts)
  Do you prefer working on it alone, or can I help in the integration or re-implementation of the missing features ?

from vscode-amiga-assembly.

You LSP project seems interesting too as a replacement of some code in the extension.

from vscode-amiga-assembly.

Quick update on this. The key things that are missing due to removing the dependency on vscode are:

• A few references to VS Code specific stuff in the DebugSession classes for things like:

  • Getting config
  • Updating breakpoints
  • Updating the disassembled view

  I think this is pretty easily solved by just extending the DebugSession classes to create VS Code specific versions which inject these calls.

• Breakpoint persistence. This was using workspace storage and for now I had just removed it. It should be fine to reimplement this using an adapter pattern where it uses a BreakpointStorage interface to abstract away the implementation. For the standalone version this could be non-persistent by default.

• Access to symbols in workspace when evaluating expressions. Without access to the workspace, expressions can only reference symbols that are present in the assembled file and not things like constants that only exist in the source. My idea for this is to pass a LocalSymbolResolver to the DebugExpressionHelper to allow access to these when they're available. For the VS Code implementation this can access the values directly from the parsed files in the workspace. For standalone I can see a few options:

  • Don't implement it!
  • Parse the source files and extract the symbols in the debugger when required
  • Use vasm to extract the symbols e.g. vasmm68k_mot -m68000 -Ftest gencop.s -o /dev/stdout. This works well and would be most accurate in matching the real parsing logic. The only slightly tricky bit is figuring out which source file(s) to process from the debug info in the file hunks. It would need to find the entrypoint for each linked object.

• Access to disassembled files. This is probably the biggest challenge. Currently this doesn't work in the standalone debugger and I'm trying to figure out a solution. When the editor gets a stack trace in a *.dbgasm file it doesn't know what to do with it as it doesn't exist on the file system. Currently in vscode this is handled by disassemblyContentProvider, which provides text documents using disassembled output from the active debugger session. I'm not sure if this will still be possible once the debugger is running standalone so I'll want to try this out. One option would be to write the disassembled files to a temporary dir and reference them with a real path.

from vscode-amiga-assembly.

1/2 ok
3 : The vasm option looks good, why not parsing all the linked files ?
4 : I've started to use the default vscode debug view. It lacks some pretty print for the copper list. That's why I didn't got rid of the dbgasm files, but I think one day they will be removed.

from vscode-amiga-assembly.

Re 3: yeah we do want to process all of the linked files, but not necessarily every source file.

For example, say I have the following files which are linked into the final executable:

• main.asm which is assembled into main.o
• another.asm which is assembled into another.o

We definitely want to process both of these source files. However...
They might also include other source files e.g. includes/routines.i. These included sources will appear in the line debug data, but are not intended to be assembled directly and don't generate their own object (hunk) files. Vasm might fail to assemble or generate different output if they were processed individually.

I'm sure it's not a problem to differenentiate these when parsing the hunk data, just something I need to figure out!

from vscode-amiga-assembly.