Amiga Assembly extension for Visual Studio Code

[JoeJoe]

@arcanist: I can agree with that. For example, WinUAE waits itself dead to connect to VSCode 1.56. Also, the output of Make files is slower. But this has nothing to do with the extension.

[emiespo]

Originally Posted by prb28

Maybe it's a problem os file signing on mac : https://github.com/prb28/vscode-amig...working-on-osx
The thread of the issue :
https://github.com/prb28/vscode-amig...bly/issues/143

Hi prb28, thanks for replying! I’ll add some details: this was “issue n.1”, that I solved using absolute paths to reach the executables from config and the “curl” trick to prevent OSX from setting the protection bit. After that the “NOENT” error is gone, but what happens is that it will only compile the main source file in the root folder, and not see anymore those in a subfolder. Unless even .s files are affected, I don’t think this is related and in this case of course it complains of missing symbols (xrefs). It will only generate “main.o” from main.s in the root directory.

I’ll try to revert VSCode tonight and see if it goes back to working! Tried to give a look at the extension source code, and it also seems nothing has changed in the build function (“doing the magic”). I should probably learn how it works and debug that… wish I had more time ahah!

[prb28]

You are right, there is something wrong with the last version of vscode 1.56.
I'm opening the debugger ....

[prb28]

Fixed in release 0.21.2 !

[prb28]

Originally Posted by emiespo

It will only generate “main.o” from main.s in the root directory.

Try to change the link options with "**/*.s" :
"amiga-assembly.vlink": {
...
"includes": "**/*.s",
..
},

[JoeJoe]

Thank you, I can confirm that the fix works great

Originally Posted by prb28

Fixed in release 0.21.2 !

[prb28]

Originally Posted by JoeJoe

Thank you, I can confirm that the fix works great

Thanks for the feedback !

[arcanist]

Originally Posted by prb28

Fixed in release 0.21.2 !

It doesn't hang now but is not stopping on any breakpoints I set. This also occurs with vscode-amiga-wks-example.

(I nevertheless appreciate the effort. This extension is invaluable for Amiga intro dev. )

[prb28]

Originally Posted by arcanist

It doesn't hang now but is not stopping on any breakpoints I set. This also occurs with vscode-amiga-wks-example.

Can you tell me a bit more :
what is your os ?
Are the dots of the breakpoint red ?
Do you have bartman extension enabled ? (there are some conflicts, it should be disabled in the workspace)



Can you try :
- add and remove the breakpoint before or during the debug
- In your .vscode/launch.json set trace to true and send me the copy of the DEBUG panel

"trace" : true

[arcanist]

Originally Posted by prb28

Can you tell me a bit more :
what is your os ?
Are the dots of the breakpoint red ?
Do you have bartman extension enabled ? (there are some conflicts, it should be disabled in the workspace)

This is on Windows. Both WinUAE and FS-UAE Debug configurations show the same behavior. bartman's extension is disabled in the workspace. The breakpoint dots are solid red.

Experimenting more it seems that some breakpoints work, but only those set fairly late into the program. e.g. In the gencop.s example a breakpoint near the beginning is missed, but one set after mainloop triggers.

Now that I think about it I've never been able to break on the very first instruction. I assumed that was a design quirk but perhaps there's an underlying race?

Originally Posted by prb28

Can you try :
- add and remove the breakpoint before or during the debug
- In your .vscode/launch.json set trace to true and send me the copy of the DEBUG panel

"trace" : true

I can't add breakpoints early in the program after debug starts. It's too fast. I can toggle them on during the run and then restart. The early breakpoints are still missed.

I've attached traces from 1.55.2+0.21.1 and 1.56+0.21.2.

[prb28]

@arcanist, yes the breakpoints in the beginning of the program (~4 instructions) are missed. That's some kind of bug that I did not address because there is the stopOnEntry option that you can activate int the .vscode/launch.json file. It does the trick, otherwise it needed a rework of the debug code of fs/win/uae.

[emiespo]

Originally Posted by prb28

Can you tell me a bit more :
what is your os ?
Are the dots of the breakpoint red ?
Do you have bartman extension enabled ? (there are some conflicts, it should be disabled in the workspace)



Can you try :
- add and remove the breakpoint before or during the debug
- In your .vscode/launch.json set trace to true and send me the copy of the DEBUG panel

"trace" : true

Hi, I managed to get the build working again (thanks!), now I have the same issue as arcanist. FS-UAE is stuck and breakpoints are not hit.

Attaching the output of the debugger window (the last traces are me trying to turn another breakpoint on and off interactively).

Mac OSX Catalina.

N.B. I just saw the other post and I have been using stopOnEntry for a long time now so there's more.

[prb28]

@arcanist, @emiespo, I agree, there something still wrong!

I'm used to put the breakpoint in the mainloop for my test and it works, but if it is at the beginning, it doesn't.

Opening the debugger .... sorry guys .

[prb28]

Partial fix : https://github.com/prb28/vscode-amig...ly-0.21.3.vsix
Works on my windows, not tested on linux and osx (may not work on these platforms).
I'll try to release it tomorrow.

[arcanist]

Originally Posted by prb28

Partial fix : https://github.com/prb28/vscode-amig...ly-0.21.3.vsix
Works on my windows, not tested on linux and osx (may not work on these platforms).
I'll try to release it tomorrow.

Seems to work fine here on Windows.

[prb28]

@arcanist : Thanks.

Fix released, hope it works for every context.
Please, report if not, it's a sensible par of the code that needs a refactoring.

[emiespo]

Originally Posted by prb28

@arcanist : Thanks.

Fix released, hope it works for every context.
Please, report if not, it's a sensible par of the code that needs a refactoring.

I just tried it, it doesn't work on OS-X.
FS-UAE starts, but then it won't hit breakpoints (nor the stop on entry).
If I click the "Continue" button [ |> ], I can see the error as in the attached screenshot.

This is version 0.21.3.

Thanks again for looking into this!

[prb28]

Originally Posted by emiespo

I just tried it, it doesn't work on OS-X.
FS-UAE starts, but then it won't hit breakpoints (nor the stop on entry).
If I click the "Continue" button [ |> ], I can see the error as in the attached screenshot.

I've just tried on a osx and it worked, but it may depend on the computer.
It looks like something else.
Can you select Menu Help/"Toggle developer Tools" and look at the console ?
I would like to get the stack trace to know what's happening.

[emiespo]

Originally Posted by prb28

I've just tried on a osx and it worked, but it may depend on the computer.
It looks like something else.
Can you select Menu Help/"Toggle developer Tools" and look at the console ?
I would like to get the stack trace to know what's happening.

Thanks! I didn't know that you would see a stack trace (made of Webkit developer tools!)... I simply had mistaken the path to `cstool`...

It seems to work again now. Still won't find local libraries (except those in ROM), but fine for now, got lots of things to complete before trying to play with the asyncio.library

[prb28]

Originally Posted by emiespo

It seems to work again now.

Originally Posted by emiespo

Still won't find local libraries (except those in ROM), but fine for now, got lots of things to complete before trying to play with the asyncio.library

To link with libraries you may need to add options to vlink or create a build with a makefile. You'll find some help in these forums for that.


(I program more in typescript than asm )