Amiblitz 3.5 Debugger doesn't work since Update 5

gerograph · Post by **gerograph** » Wed Sep 26, 2012 8:22 am

@Hypex
just tried AmiBlitz on my SAM440ep after updating to upd.5. Works without any problem.... So it must be down to 1) processor or 2) differences between upd5 on SAM and on X1000 ???

EDIT: tried to comment all petunia related stuff in Kicklayout and did a hardreset, still same problem.

Post by **Hypex** » Wed Oct 10, 2012 5:15 am

Given that JIT had to be disabled for the debugger either way I would point to the ExecSG kernel 68K emulation. Something must have broke when they ported the kernel over to the X1000. Since it is an emulation issue.

I think Petunia needs some work as well since these exceptions fail to work with it. I suppose with dynamic generated code it is hard to catch an exception condition but it should be programmed to deal with it. Or at least pass it to the ExecSG emulator.

We could cite the CPU as making the difference here but it is the emulation which has broken. I don't know if the emulator has PPC assembly but given it is a static emulator it shouldn't need to a 68K emulator can be written in portable C and with the trapcode exceptions here most would be emulator triggered. In the case of a trap, it would interpret the trap command and emulate the behaviour. That is set the CPU to super mode, stack the SR and PC, and put the trap number on the stack. And pull the trapcode from the task and put in the PC. Execute until an RTE. Like on any other emulator it just simulates an interrupt.

However I am aware that the exception emulation can occur in the super mode of the host PowerPC processor. So the lines can be blurred. Though that sounds like it is taking it too far.

gerograph · Post by **gerograph** » Mon Dec 03, 2012 5:27 pm

@all
after discussing the matter with AmiBlitz Devs, the solution seems simple. Hypex is on the "right track" as bernd_ found out. This is what bernd_ (AmiBlitz Dev) wrote on the AmiBlitz Forum (tried to polish the language a bit / original quote, see below):

An exception for 68k does not need a PPC exception, the 68k emulation just needs to look whether a 68k excpetion happens as trap #1, illegal looks into the 68k vector table if there is an address set for the handler.

Old blitz basic uses task traps for this, (remember when amiblitz had the great feature of runtimecheck, overflow and correct parameter checking in function calls, therefor all this is needed) but I "hacked" amiblitz in an easy and fast to accomplish way (...) to work with OS4. This workaround was done, because "blackbird" wanted to write programs on PPC. The only thing OS4 needs to do (already added around 2005 in OS4), is to continue at the vectoraddress. This works on SAM upd 5 but not on X1000. Strange though, that X1000 is the only machine, where it doesn't work. Runtime overflow check and parameter check is an important feature and helps to avoid total crash on functioncalls with wrong parameters. Thats not possible if you use C and the gdb stuff.
Code: Select all
vectorbase is in a0. 
CNIF #tasktrap=0 
MOVE.l #AJL_0_7E4,$80(A0) ;trap #0 
MOVE.l #AJL_0_606,$84(A0) ;trap #1 
MOVE.l #AJL_0_5C8,$88(A0) ;trap #2 
MOVE.l #AJL_0_5FE,$8C(A0) ;trap #3 
MOVE.l #AJL_0_50E,$90(A0) ;trap #4 
MOVE.l #AJL_0_558,$94(A0) ;trap #5 
CEND 

..... 

AJL_0_606: ;store register 
BTST #$5,(A7) 
BNE.w JL_0_646 
MOVE.l $2(A7),AL_0_7DE 
MOVE.w (A7),AL_0_7E2 
MOVEM.l D0-D7/A0-A6,AL_0_79E 
MOVE.l USP,A0 
;MOVE.l a7,A0 
MOVE.l A0,AL_0_7DA 
LEA AL_0_79E(PC),A0 
MOVEA.l AL_0_146(PC),A1 
L_0_634: 
JSR (A1) 
BNE.b JL_0_64C 
TST.b AL_0_12A 
BNE.b JL_0_64C 
MOVEM.l L_0_7BE(PC),A0-A1 
JL_0_646: 
ADDQ.l #8,$2(A7) 
RTE 

JL_0_64C: 
MOVE.l #AJL_0_656,$2(A7) 
RTE 
The 68k emu for example: trap #1 should put the register on 68k stack as described in 68k docu and jump to #AJL_0_606

Here someone can find the complete source. Due to the fact, that AmiBlitz Debugger is from "Redwhen excited" and not from acidlib, there wasn't any source. Therefor reassembled it and documented it as far as I needed, to change from tasktrap to 68k vector trap in order to work on OS4.

http://amiblitz3.svn.sourceforge.net/vi ... 2?view=log

Here is the original quote:

A exception for 68k need no PPC exception, the 68k emulation need just look when a 68k excpetion happen as trap #1, illegal look in the 68k vector table if there is a address set for the handler.

old blitz basic use task traps for this, (remember amiblitz have the good feature of runtimecheck, overflow and correct parameter checking in function calls, so all this is need) but i hack amiblitz in easy and fast to add way(because i see no revival of amiga with PPC OS4, i dont spend more work to support PPC better) to work with OS4, because blackbird want write programs for it. The only thing OS4 need to do(and is add around 2005 in OS4), is to continue at the vectoraddress. this work on SAM upd 5 too, but not on X1000. strange wy it not work only on X1000. runtime overflow check and parameter check is a important feature, and help to avoid total crash on functioncalls with wrong parameter. thats not possible if use C and the gdb stuff.

vectorbase is in a0.
CNIF #tasktrap=0
MOVE.l #AJL_0_7E4,$80(A0) ;trap #0
MOVE.l #AJL_0_606,$84(A0) ;trap #1
MOVE.l #AJL_0_5C8,$88(A0) ;trap #2
MOVE.l #AJL_0_5FE,$8C(A0) ;trap #3
MOVE.l #AJL_0_50E,$90(A0) ;trap #4
MOVE.l #AJL_0_558,$94(A0) ;trap #5
CEND

.....

AJL_0_606: ;store register
BTST #$5,(A7)
BNE.w JL_0_646
MOVE.l $2(A7),AL_0_7DE
MOVE.w (A7),AL_0_7E2
MOVEM.l D0-D7/A0-A6,AL_0_79E
MOVE.l USP,A0
;MOVE.l a7,A0
MOVE.l A0,AL_0_7DA
LEA AL_0_79E(PC),A0
MOVEA.l AL_0_146(PC),A1
L_0_634:
JSR (A1)
BNE.b JL_0_64C
TST.b AL_0_12A
BNE.b JL_0_64C
MOVEM.l L_0_7BE(PC),A0-A1
JL_0_646:
ADDQ.l #8,$2(A7)
RTE

JL_0_64C:
MOVE.l #AJL_0_656,$2(A7)
RTE

and the 68k emu for example trap #1 should put the register on 68k stack as descripe in 68k docu and jump to #AJL_0_606
here is complete source. because the debugger is done from redwhen excited, and not from acidlib there was no source, so i reassemble it and document as far i need, to change from tasktrap to 68k vector trap to work on OS4.

http://amiblitz3.svn.sourceforge.net/vi ... 2?view=log

So, can somebody do something about that please ? My new AmiUpdate

is waiting (Great job by the way...)

regards Gero

Post by **Hypex** » Wed Sep 04, 2013 3:00 pm

I've just done some tests with trap handlers on both my AmigaOne and X1000. All with static emulator. And I have found that the X1000 kernel does infact execute trap handlers perfectly fine. Division by zero and trap instructions work. So what is AmiBlitz doing?

Well thew above code is slightly confusing. Also, on my AmigaOne, the debugger starts but doesn't seem to work as it should. I can single step so far and then it just stops. no crash it seems, the window doesn't respond. Also after using it the debugger seems hard to use or bring up. I just want to load it and give it a program to single step through but ti doesn't seem to work like that. Here I always have to go into the compiler settings, enable debug info, compile and that triggers it off. And it never saves my settings nor has a save gadget! What the?

From my sources on TrapCode exceptions the trap number is put on the stack after the stack frame generated by the CPU. But, the above code looks like it tests bit 5 ($20 or 32), from the first 16-bit word of the trap number and conditionally adds 8 to a long word starting at its low-word . Huh!? I don't know what it is doing and if it works on a real Amiga it's hard to dispute it as being bugged. Obviously the programmer has better documentation than I do. I didn't know if $20 was set in the high word of the trap number then it isn't really a trap number and other numbers are in its place.

Either way. Trap code exceptions work on the X1000, so I don't know what is breaking AmiBlitz.

gerograph · Post by **gerograph** » Sun Sep 08, 2013 4:41 pm

@Hypex

thanks for looking into this once more. This is what normally happens (on my SAM e.g. or WinUAE/AOS 3.9):

1) Put
../Amiblitz3.5/Debug/REDDebugger
../Amiblitz3.5/Debug/defaultdbug
../Amiblitz3.5/AmiBlitz3

on your JIT-Emulator Blacklist

2) Open AmiBlitz and Load "Blitz3:Sourcecode/Examples/dbl_simple_01.bb2 (or any other small #?.bb2 or #?.bb3 source file)

3) Go to Menu Compiler -> Compiler Settings and Tick "Runtime Error Debugger", "Auto Run", "Interrupt checking".

4) "Save (!)" or "Save as" your sourcecode, use bb3 as file extension (it will then be saved in BlitzBasic3 format rather then BlitzBasic2) This will also save your compiler settings for this file

5) Define a breakpoint in your source by inserting "stop" in your sourcecode

6) Menu Compiler -> compile and run

7) Debugger will (normally) pop up and show the code around your "breakpoint" in a separate Debug Window, now you can "Step" throug your code via Gadget in top window. On X1000 I'll get a GRIM just after Debugger was started and before code is shown. I can still use REDDebugger Menu and do some Debugger Settings (like choose Screenresolution etc...) and save settings.

Hope this helps. AmiBlitz + Debugger is working perfectly well on my SAM440 and AOS 3.9. I'll submit your "results" into Amiblitz board/forum. Maybe people there can comment and shed some light on it!

EDIT:http://www.amiforce.de (Amiblitz Forum) is currently down, so once it is up I'll crosspost and try to contact AmiBlitz Devs there!

Regards Gero

Post by **Hypex** » Mon Sep 16, 2013 4:11 pm

@gerograph

Thanks for the instructions and hints. It does look like AmiBliiz is slightly more complicated than I antcipated. I've never edited a source before to program a debugger what to do. Well not since I inserted ILLEGALs to stop AssemPro.

So it looks like the process is not what I'm used too. Like the AmigaE debugger which I found easy to use. Just load the program and start stepping in it. Not from an IDE but you just loaded and stepped with no hassle. For some reason AmiBlitz doesn't work this way. I don't know why, it's simple way to work. Perhaps AmiBlittz is like Apple's XCode, where you can't load and step either. What is it with these debugggers where you can't test code without making it crash or stop first? I guess I just don't get it, even though I have used debuggers to track and locate bugs. Well never mind.

Anyway I followed your instructions. And the process breaks on my A1-XE as well. I inserted a STOP down the bottom of the code after the main loop where it checks for mouse event. I compiled and run it. A window comes up with a note about a privilege volation guru. I thought it may be a preset trap caught by the debugger so ignored it. I was able to step through the code but it looked strange (fully expanded I take it) and it didn't "feel" correct, it didnt feel llike I was single stepping. Then I tired of that and decided to run it until it hit the stop. It didn't make it. The machine froze! I could recover with a reboot and see the crash log. One crash ended up in a trap. Blitz ][ Program Proc crashed also.Will check my JIT settings.

Hidden Text - Click to Show :

gerograph · Post by **gerograph** » Wed Sep 18, 2013 11:54 am

I was able to step through the code but it looked strange (fully expanded I take it) and it didn't "feel" correct, it didnt feel llike I was single stepping.

The Debugger also steps through the "Includes", you can switch that on off while debugging (cannot remember which button that was). This might be the reason...

I suggest to start with a very simple code example and put the STOP right at the beginning. I could then try the very same code on WinUAE. If I find some time I'll post a bit of code here, which we both could use.
However, I am still trying to get hold of one of the Amiblitz Developers, but it seems www.amiforce.de is down for the moment

regards Gero

Post by **Hypex** » Thu Sep 19, 2013 5:34 pm

gerograph wrote:I suggest to start with a very simple code example and put the STOP right at the beginning.

Okay, looks like I had missing file on my blacklist, though don't know what happened there. As I'd tested it working on my A1 months ago. So I tried again and it works as expected.

Now to find out why it breaks on the X1000. Hard to know what it is doing. Need a test case that generates an exception; working on the A1 and breaking on the X1000.

BTW also posted a bugzilla on both static and JIT emulator for ILLEGAL instruction breaking in trapcode. Being TRAP is support no reason ILLEGAL can't be. Does the same thing in effect.

Hyperion Entertainment Message Boards

Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5

Re: Amiblitz 3.5 Debugger doesn't work since Update 5