search

prb28 / vscode-amiga-assembly

Amiga Assembly extension for Visual Studio Code
GNU General Public License v3.0
178 stars 12 forks source link

Traps are not processed properly #263

Closed Real-MJoe closed 10 months ago

Real-MJoe commented 1 year ago

In the latest version 1.8.0 and 1.8.2 the debugger is not triggered on a trap. Also an own breakpoint is not triggered. The processing of the code is stoped by a "hidden" break.

In version 1.6 the debugger is triggered correctly by the traps and the own breakpiont is set to bsr.w dummy_sub is also respected accordingly. grafik

Workaround: When the process stops hidden again, actively trigger the debugger via F6 or pause key in VS code. The debugger stops at the right place. grafik Pressing F5 will continue to run the code. If you do this a total of four times then your own breakpoint will be triggered.

This can be reproduced by a small function that disables the caches. A workspace can be loaded here. Simply install the extension in the right version and the associated lauch version "WinUAE Debug (1.8.1)" or "WinUAE Debug (1.6)" select.

many greetings

prb28 commented 1 year ago

Thanks for this really well described issue report ! @grahambates can you work on this issue please ?

prb28 commented 10 months ago

@grahambates did you have time to look at this issue ?

grahambates commented 10 months ago

Ah, no I completely forgot about this one. I'll have a look at it tomorrow.

grahambates commented 10 months ago

The changes I've made should hopefully bring the functionality back in line with the WinUAE implementation in v1.6.

One thing I did notice though, was that the old FS-UAE fork was more complete in terms of handling specific exceptions and returning appropriate codes and descriptions. Bartman's implementation (which was always used in WinUAE and is now used in FS-UAE too) only specifically handles address errors and illegal instructions. Everything else just gets returned as a generic S05 code, which until now wasn't being handled correctly.

At some point I'd like to add a more complete implementation and update the emulator binaries, but this should do for now.

prb28 commented 10 months ago

I've published it in 1.8.5 version, waiting for the validation from the marketplace.

fredrik-m-j commented 10 months ago

I get this in easystart.i using WinUAE Debug:

image

Proceeding as normal after that.

grahambates commented 10 months ago

@fredrik-m-j I assume there's no reason why you'd expect that line to trigger an exception? Do you have stopOnEntry set? Maybe it's incorrectly flagging that as an exception. I'll do some more testing on WinUAE.

grahambates commented 10 months ago

That was the indeed problem. It was sending two events when stopping on entry, type 'entry' and also type 'exception' from the default handler. I've fixed it and opened another PR.

prb28 commented 10 months ago

@grahambates there is a exception thrown on each step in debug with the last uae-dap.

grahambates commented 10 months ago

Whoops! Don't worry I'll sort it.

grahambates commented 10 months ago

@prb28 sorry, I've just seen there was an issue the the Mac binary on the version you just merged. I will get this right eventually!

grahambates commented 10 months ago

Actually I think that was a false alarm, but I do need to do some more thorough testing. I'm planning to do some work on my demo tomorrow so hopefully that should put it through its paces a bit.

prb28 commented 10 months ago

My simplistic unit tests worked on mac, but they are far from being a grantee of a working extension...