Amiga Assembly extension for Visual Studio Code

[prb28]

Do you have the stopOnEntry option set ?
Could you remove the built files and try to rebuild all the workspace?
I’ll try it on windows, maybe a bug...

[Jeeg]

I set the stopOnEntry and trace to true and after rebuilding the project it worked. Thank you very much for your advices.

[emiespo]

Originally Posted by Jeeg

I set the stopOnEntry and trace to true and after rebuilding the project it worked. Thank you very much for your advices.

Hi, I'm facing the same issue. I've tried to delete the build folder, but no lack.

EDIT: I've also set both options to true, but it still stops elsewhere and is out of sync with code lines.

I've an 'include startup.s" right at the top that might confuse the debugger?

EDIT2: I think I've got the issue. I don't see all the files being rebuilt, but just the main module and another I've touched... what's the proper way to clean the build then?

[Antiriad_UK]

Yes includes like that confuse the debugger. Makes sense as the line number vs source file name info that is stored in the exe cant/wont match. You get similar problems with macros and rept structures.
I’ve moved to a style where I assemble everything separately and the have them all linked. So like your include startup I have that as its own file to be assembled and linked so if it needs to be debugged it can easily work out the correct file.

You can probably get away with just putting a breakpoint as the first line after your include when debugging starts it should stop there (may need to press f5 once if using stoponentry)

[emiespo]

Originally Posted by Antiriad_UK

Yes includes like that confuse the debugger. Makes sense as the line number vs source file name info that is stored in the exe cant/wont match. You get similar problems with macros and rept structures.
I’ve moved to a style where I assemble everything separately and the have them all linked. So like your include startup I have that as its own file to be assembled and linked so if it needs to be debugged it can easily work out the correct file.

You can probably get away with just putting a breakpoint as the first line after your include when debugging starts it should stop there (may need to press f5 once if using stoponentry)

Thanks. In fact I've noticed that before deleting the build folder, I had a lot of ".o" files in there... now it tries to build a single file every time I save it, and obviously it doesn't work as it can't find macros, etc...

I think I might have assembled them in a different way, but really can't remember how :-) what I remember is that the debugger was working like a charm.

Would you suggest building all separately with Vasm? Is there any example I could look at? I only code a few lines every few months (sad) that's why I keep forgetting...

[Antiriad_UK]

The design of the extension and default config is such that it will auto compile anything with an .s extension. So it gets a bit messy for programs with multiple source files where some are included manually and others aren't. You can of course rename files that you want to include but not automatically assemble to startup.i or something.

Personally, I love the extension for the in editor tools and debugging, but I'm finding it easier to do the build myself with a batch file (can use a makefile of course, but I doubt I'll ever have more than a dozen files)

My vscode config for the extension in launch.json I removed the auto build:

            "buildWorkspace": false,

Example batchfile I'm using to assemble and link my multiple files. I just run the batch and then jump back into the editor to run the debug.

@set DemoName=Demo

@rem General build params
set BuildParam=-m68000 -showopt -Fhunk -kick1hunks -linedebug -x -DDebug=%Debug% -I Include -D_INTROWRAPPER=0 -nowarn=62

@rem General linker params, strip symbols unless debugging
set LinkParam=-bamigahunk -Bstatic
if %debug% NEQ 1 set LinkParam=%LinkParam% -s

REM Assemble all sections and link together. Assemble entry point file first
set ObjFileList=

set SrcFile=Framework\IntroStandalone.s
set ObjFile=%ObjDir%\IntroStandalone.o
ECHO ASSEMBLING: %SrcFile%
vasmm68k_mot_win32.exe %BuildParam% -o %ObjFile% %SrcFile%
if errorlevel 1 goto failed
set ObjFileList=%ObjFileList% %ObjFile%
ECHO.

set SrcFile=Framework\IntroFramework.s
set ObjFile=%ObjDir%\IntroFramework.o
ECHO ASSEMBLING: %SrcFile%
vasmm68k_mot_win32.exe %BuildParam% -o %ObjFile% %SrcFile%
if errorlevel 1 goto failed
set ObjFileList=%ObjFileList% %ObjFile%
ECHO.

REM ...
REM More files go here and repeat the above for each file
REM ...

REM Link objects
echo.
echo LINKING %DemoName%

vlink %LinkParam% -o %OutDir%\%DemoName%.exe %ObjFileList%
if errorlevel 1 goto failed

echo SUCCESS
exit /b 0

:failed
echo FAILED
exit /b 1

[prb28]

For bigger builds, one better way to do it is using a makefile. Here is an example: https://github.com/prb28/vscode-amiga-vbcc-example.
It’s with a mix of C and ASM but you can remove the C build instructions.

[Antiriad_UK]

Nice. I’ll take a look

[emiespo]

Originally Posted by prb28

For bigger builds, one better way to do it is using a makefile. Here is an example: https://github.com/prb28/vscode-amiga-vbcc-example.
It’s with a mix of C and ASM but you can remove the C build instructions.

I've used vasm to get the list of files - from the includes - to generate a makefile, and it worked seamlessly from the command line. Something like:

vasm -depend=list ...

the main source file is then successfully compiled via "make" into one single exe, however VisualStudio is still unable to correctly detect my breakpoints. Even the entry breakpoint is not correct. I remember it used to work earlier, but then I haven't touched it in a while...

[prb28]

Originally Posted by emiespo

I've used vasm to get the list of files - from the includes - to generate a makefile, and it worked seamlessly from the command line. Something like:

vasm -depend=list ...

Please check that :

- you use the vasm option : -linedebug
- The launch.json configuration parameter "program" is correct

[emiespo]

Originally Posted by prb28

Please check that :

- you use the vasm option : -linedebug
- The launch.json configuration parameter "program" is correct

Thanks for your reply. My config seems to be correct, I guess that the environment is trying to assemble all files as separate object files (.o) and this confuses the linker.

Now I get a bunch of:

Error 21: init_copperlist.o (CODE+0x7e): Reference to undefined symbol CprPln1.

...if I try to define those symbols, eventually I get:

Error 19: /build/main.o: Global symbol bplxmod from main.o is already defined in copperlist.o.

It seems that main is already including the symbol, but since "vlink" is called on all the .o files generated singularly, it gets confused as it sees some symbols twice.

This would also explain why if I only link main.o (main.s includes files including other files in turn) the exe works but the debugger doesn't.

What confuses me is that I am pretty sure it was working a few months ago, and I was really happy to get this kind of functionality as in the past I used to debug UAE via RAM breakpoints, ie breakpoints triggered by writing 0 at specific addresses in RAM...

[prb28]

Maybe the debugger can’t reach the sources and you have to set the sourceFileMap option in the launch.json file. The best way to check it is to open the exe with a hex editor and see if there is debug info and the name of the files in it.

If you want to the easiest way for me to check it is to build your project on my desktop. If you want you can send me a link in pm, and I’ll have a look next week (I’m far from a computer this weekend).

[emiespo]

Originally Posted by prb28

Maybe the debugger can’t reach the sources and you have to set the sourceFileMap option in the launch.json file. The best way to check it is to open the exe with a hex editor and see if there is debug info and the name of the files in it.

If you want to the easiest way for me to check it is to build your project on my desktop. If you want you can send me a link in pm, and I’ll have a look next week (I’m far from a computer this weekend).

Thanks a lot for your support!

I am now thinking that the editor doesn't (still) support multiple sources. I've tried something simpler that you could easily replicate, I've downloaded the example workspace here: https://github.com/prb28/vscode-amiga-wks-example

and then added as the very first file a "test.s" with just one instruction. I've set up a breakpoint to this single instruction, and it is completely ignored (see the attached screenshot).

The debugger only seem to take into account the breakpoints set in the main source. Now I wonder if it has ever worked - as I happen to remember - or it was "just my imagination". Either way, this is an awesome project, pretty sure it will become THE Amiga IDE

EDIT: to add more info to my investigation, I've noticed that if I set the instruction in "test.s" at line 5, and start the debug with "stopOnEntry", the debugger will stop at the very beginning of the file, the disassembler will show an empty instruction there. If I then jump one step, the debugger will jump at line 5, where the instruction in "test.s" actually is!

Hope this helps understanding what is missing/wrong, cheers!

[prb28]

Hopefully it supports multiple files projects ;-).
But be careful, the program starts at the first linked source, you should set it’s name in the settings.
Actually there is a bug due to how it’s implemented in fs-uae and extension that prevents adding a breakpoint in the 2 or 3 first lines. So the stoponentry is mandatory in this case.

[emiespo]

Originally Posted by prb28

Hopefully it supports multiple files projects ;-).
But be careful, the program starts at the first linked source, you should set it’s name in the settings.
Actually there is a bug due to how it’s implemented in fs-uae and extension that prevents adding a breakpoint in the 2 or 3 first lines. So the stoponentry is mandatory in this case.

I still think it doesn't work properly I was already using the "entrypoint" option.

Things I've tried:

Include the ".s" inline ---> doesn't work (see attached screenshots)

Use a XREF/XDEF pair + a JSR to it later in the source ---> doesn't pick up the breakpoint on the separate file

Breakpoints on included files seem to never be encountered. "Test.s" accepts the breakpoint (red dot) while test2.s becomes grey while the debugger is running.

[Antiriad_UK]

You can’t set a break point on an included file. You have to not use include. Let the extension auto assemble test.s and test2.s itself and use xref and xdef. It all works fine then. I’ll knock up an example tomorrow

[emiespo]

Originally Posted by Antiriad_UK

You can’t set a break point on an included file. You have to not use include. Let the extension auto assemble test.s and test2.s itself and use xref and xdef. It all works fine then. I’ll knock up an example tomorrow

I've tried that as well... I've added a

jsr xrefSymbol

code was executed fine, but the breakpoint (in the external file) was not picked up.

The external file looked like:

     xdef xrefSymbol

xrefSymbol:
     moveq #0,d0
     rts

[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.

[prb28]

Back, in front of my computer! (sorry for the partial answers)
So I've tried the code... and ... filed a bug to investigate further: https://github.com/prb28/vscode-amig...mbly/issues/90
@emiespo, you're right there is something weird when including a .s file, the produced source does not contain all the lines info and looks like a mess. I must dig some more with a hexdump to see what's happening.

The inner part of the simplistic implementation of the build process in the extension is -> build every source file, then link them all (you can select the first one - it's the entry point).
It's simple and straightforward for people starting asm on amiga, but it's too simple for a "real" project.
And in this case seems to be a bad choice. 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.

And @Antiriad_uk, thanks!
Your solution and support is great.

I will add next info in the github issue, just for keeping track of it, feel free to add some comments in it's discussion.

[Antiriad_UK]

Originally Posted by prb28

@emiespo, you're right there is something weird when including a .s file, the produced source does not contain all the lines info and looks like a mess. I must dig some more with a hexdump to see what's happening.

Yeah I saw that when I opened up a file in hex (I was just curious how any of this works at all!). Saw that it's linenumber/source file based.
You get the same effect with macros or REPT, the debugger jumps to line zero while you are single stepping and then back to the correct line number after.