Amiga Assembly extension for Visual Studio Code

[phx]

Originally Posted by prb28

I've to look what vasm and vlink docs say about this scenario. I don't know if including a ".s" file is support by the -linedebug option.

No, not yet. Sorry.
-linedebug is currently a Q&D solution in the hunk output module, which always puts the name of the main source file in the LINE debug header.

I already implemented a more sophisticated source file management for DWARF debug sections. So the information is theoretically available. I might have a look in improving -linedebug over the next days...

[prb28]

Originally Posted by phx

No, not yet. Sorry.
-linedebug is currently a Q&D solution in the hunk output module, which always puts the name of the main source file in the LINE debug header.

Thanks for this info.
And what about the macros ?
I imagine it's the same problem.

Originally Posted by phx

I already implemented a more sophisticated source file management for DWARF debug sections.

Maybe the way to go is to implement the DWARF parsing in the extension. I've started reading the specs.. but it's a long way to go !

[phx]

Originally Posted by prb28

And what about the macros ?
I imagine it's the same problem.

Yes, quite similar. Macros and repetitions also create a new source text instance with their own line numbers. But in this case I should better fetch the real line number from the parent source structure.

Maybe the way to go is to implement the DWARF parsing in the extension. I've started reading the specs.. but it's a long way to go !

Unfortunately DWARF sections make no sense with Amiga hunk format. Unless you define a method to hide them in HUNK_DEBUG blocks. But I don't want to define a new debug-format here.

Let me have a look at improving -linedebug first.

[emiespo]

Originally Posted by Antiriad_UK

Just knocked this up (you'll need to replace the bin folder with your windows/mac binaries)

https://www.autoitscript.com/files/a...de-example.zip

3 files:
main.s - entry point
test1.s - contains test1Func
test2.s - contains test2Func

I find it works best if you set the breakpoint first, then build, then run in Debug. Sometimes it doesn't work if you build then set breakpoint. I tried setting a breakpoint in both test1/test2 and it stopped on both.

Hey thanks everyone for taking time to look at this It would be great for me even to have it working with xref / xdef blocks.

Still, while this simple example seems to be working right, simply adding xdef/xrefs to the copper example project is quite flaky, at least on my setup (OSX). Sometimes breakpoints only work in one file, don't know why...

Anyway, having separate modules seems to be a good coding practice, I'm going to refactor my real project into smaller modules (and go for a makefile in the meantime).

I will add all of your names to the credits thanks!...

[Antiriad_UK]

Send me your project and I’ll have a look. jon @ autoitscript.com

[phx]

Originally Posted by prb28

Thanks for this info.
And what about the macros ?
I imagine it's the same problem.

Ok, now I analyzed the source and know what to do. The problem with macros and repetitions is easy to solve. Currently they store the line number from inside their own macro/rept-block, so I only have to offset it with the current line number of the real parent source text.

To allow inclusion of code from different source texts I would have to add another DEBUG-LINE hunk with a base-offsets and a different file name, just like the linker would do when merging multiple files. When returning from an include another DEBUG-LINE hunk has to be created which resets the file name and current section offset of the previous source.

Working on it...

EDIT: Done. First tests look ok. Macros, repetitions and multiple source files are supported. Please try tomorrow's vasm source snapshot: http://sun.hasenbraten.de/vasm/index.php?view=source

[prb28]

Originally Posted by phx

EDIT: Done. First tests look ok. Macros, repetitions and multiple source files are supported. Please try tomorrow's vasm source snapshot: http://sun.hasenbraten.de/vasm/index.php?view=source

Thanks !

I've tests it and the included file's breakpoints are resolved.
I'll bundle it the next release.

[Antiriad_UK]

Thanks phx, that’s great of you!

Edit: Works great for rept

[emiespo]

Thanks again from me, I'll be waiting for the next release.

In the meantime I did two things:

• built vlink and vasm from the nightly sources
• converted all my include --> include sources into separate modules, + STRUCT(s) (from exec/types), relocated all variables into a separate module

...the debugger seems to pick up breakpoints sometimes - but fails after a few steps - especially on jsr/rts - and seems to also mess fs-uae status (I see the stack pointer getting corrupted during subroutine X, but if I put the breakpoint right after subroutine X, it works up until the next jsr.

I've also noticed that changing the emulated machine changes mileage with the debugger. So it seems that fs-uae is also responsible for these issues.

Hope this information might help. Soon this will be the Amiga development environment.

Better than an asm/C compiler + debugger there could only be a Blitz Basic compiler + debugger (Blitz supports including asm sources if I am not mistaken ).

Cheers!

[prb28]

Originally Posted by emiespo

...the debugger seems to pick up breakpoints sometimes...

That's interesting, if you find a way to reproduce it, please add an issue in the github project. I'll try to fix it.

Originally Posted by emiespo

I've also noticed that changing the emulated machine changes mileage with the debugger. So it seems that fs-uae is also responsible for these issues.

Yes it comes from fs-uae and even if I got my hand on it, it's still a dark place for me.
I always found the stack trace weird, the first lines (in the program) are normally ok but the rest.... looks like a fs-uae inner mess.

Originally Posted by emiespo

Hope this information might help. Soon this will be the Amiga development environment.
Better than an asm/C compiler + debugger there could only be a Blitz Basic compiler + debugger (Blitz supports including asm sources if I am not mistaken ).

There are other projects emerging to debug amiga emulator from sources !
Like beebo's gcc with eclipse and bartman with gcc and vscode.
They should fit better for "THE Amiga development environment contest" than mine !


And it's open source so help and push requests are welcome !



Thanks for you return !

[emiespo]

Originally Posted by prb28

That's interesting, if you find a way to reproduce it, please add an issue in the github project. I'll try to fix it.

I found a way to get rid of it actually! Let me explain what I did: I tried to reinstall everything from scratch on a Windows machine... given the totally different env - and the fact that the config file was in a hidden folder, thus not synched by Google drive - I used a config file copied from the pre-built dev environment, and slightly adapted it to my project.

You know what? It worked! No longer a stuck debugger and skipped breakpoints... I then copied this config over to my OSX env, and guess what? It also works. As simple as it sounds, it might be a good advice to tell people to stick with the default config or else the debugger might stop working...

I'll now resume my project, stay tuned! ;-)

[prb28]

Originally Posted by emiespo

You know what? It worked!

Happy to hear that ! But it's still a mystery for me...



I'll keep it in mind for next issues.

Originally Posted by emiespo

I'll now resume my project, stay tuned! ;-)

Happy coding ! Have fun !

[emiespo]

Originally Posted by prb28

Happy to hear that ! But it's still a mystery for me...



I'll keep it in mind for next issues.



Happy coding ! Have fun !

So I made some more tests. What works is the default config with A1200 as the emulated machine, and the AROS ROM replacement. If I switch to a real ROM (OS 3.1) the debugger starts misbehaving badly.

Another couple of issues:

1. Macros can't be debugged, the disassembler doesn't show anything, but you can still put a breakpoint and press play out of them. Not a big deal ;-)
2. The BSR/BRA instructions lock the debugger if you press the "Step Over" icon, while they work fine with "Step Into". This could possibly be fixed, I assume

Thanks again, making again some progress...

OT: does anyone know of a site with some examples of decent os-friendly Intuition programming? I've noticed that Piru's startup doesn't work with AROS 68K, I get a blank screen now, so I am looking into opening a standard Intuition screen and manage double buffering manually (replacing the bitmap pointers is all I need).

Cheers!

[prb28]

Originally Posted by emiespo

So I made some more tests. What works is the default config with A1200 as the emulated machine, and the AROS ROM replacement. If I switch to a real ROM (OS 3.1) the debugger starts misbehaving badly.

Never tried the OS 3.1 rom, I'll try it.

Originally Posted by emiespo

Macros can't be debugged, the disassembler doesn't show anything, but you can still put a breakpoint and press play out of them. Not a big deal ;-)

I'll add issue on github and test it. Thanks.

Originally Posted by emiespo

The BSR/BRA instructions lock the debugger if you press the "Step Over" icon, while they work fine with "Step Into". This could possibly be fixed, I assume

Yes that's a point in the first implementation of the fs-uae debugger from emoon. First I thought it had to be modified (I'm used to java/C debuggers)... but for assembly code it may make sense like that.
If there are some other points of view, I would like to ear them !

[emiespo]

Originally Posted by prb28

If there are some other points of view, I would like to ear them !

Well, one more insight on this:

jsr

seems to work as expected, ie the skip button works. I wonder if it's the fact that the assembled code might have a difference due to optimizations there? as in a "bra.s" converted to "bra.w" or "jmp"?

[prb28]

New Release 0.18:

• Numerical popups with parametrized format and ASCII representation
• Format a document with TABs
• Enhanced formatting for generated data: dc.w $0 -> dc.w $0000
• Gdb protocol review (new fs-uae binaries)
• Bug fixes (windows uppercase filename in debug and others)

[hooverphonique]

Is the 0.18 example workspace supposed to work out of the box? When I try to launch the debug config, I get a dialog saying "Invalid program to debug -review launch settings".
In "launch.json", it says:
"windows": {
"emulator": "${workspaceFolder}/bin/fs-uae.exe",
},

and when I run that exe manually, I get an Aros kickstart screen.
I just installed the vscode extension and haven't used any earlier versions.

vscode 1.38.1, windows 10 64bit.

edit: the run config seems to work. and after running that, debug also seems to run, but doesn't stop at breakpoints.

[prb28]

Originally Posted by hooverphonique

Is the 0.18 example workspace supposed to work out of the box?

You're right it should.
And.. it's not working on windows.
Sorry !

Originally Posted by hooverphonique

edit: the run config seems to work. and after running that, debug also seems to run, but doesn't stop at breakpoints.

At least, I saw that, in the workspace file, the binaries are missing a ".exe".
Try to build again (with the button on the status bar).


I'm not on a windows right now but I'll check it later and will update the release tonight.

[prb28]

Seems to work out of the box on windows.

Please try :

• Open the workspace in vscode (not the folder)
• Open gencop.s file
• Build the source with the build button on the status bar
• Place a breakpoint in line 32
• Select the debug config
• Type F5

You should stop on line 32.

It works on my windows 10 64b worstation.
Tell me if it worked.

[hooverphonique]

Originally Posted by prb28

Seems to work out of the box on windows.

Please try :

• Open the workspace in vscode (not the folder)
• Open gencop.s file
• Build the source with the build button on the status bar
• Place a breakpoint in line 32
• Select the debug config
• Type F5

You should stop on line 32.

It works on my windows 10 64b worstation.
Tell me if it worked.

Yes, this seems to work now - I tried the stopOnEntry as true once, which worked, then set it back to false, and then breakpoints worked - it could very well have been something else I did that "fixed" it though.. Thanks!


Btw, I think there's a rogue "emulator" line in launch.json line 9.


I made a couple of pull requests for some fixes to gencop.s btw