Amiblitz 3.5 Debugger doesn't work since Update 5

AmigaOne X1000 platform specific issues.
User avatar
gerograph
Posts: 95
Joined: Sun Mar 25, 2012 9:24 am
Location: Moers
Contact:

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

Post by gerograph »

@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.
User avatar
Hypex
Beta Tester
Beta Tester
Posts: 696
Joined: Mon Dec 20, 2010 2:23 pm
Location: Vic. Australia.

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

Post by Hypex »

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.
User avatar
gerograph
Posts: 95
Joined: Sun Mar 25, 2012 9:24 am
Location: Moers
Contact:

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

Post by gerograph »

@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
User avatar
Hypex
Beta Tester
Beta Tester
Posts: 696
Joined: Mon Dec 20, 2010 2:23 pm
Location: Vic. Australia.

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

Post by Hypex »

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. :-?
User avatar
gerograph
Posts: 95
Joined: Sun Mar 25, 2012 9:24 am
Location: Moers
Contact:

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

Post by gerograph »

@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
User avatar
Hypex
Beta Tester
Beta Tester
Posts: 696
Joined: Mon Dec 20, 2010 2:23 pm
Location: Vic. Australia.

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

Post by Hypex »

@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 :
68k EXCEPTION 3: PC=0x02098EC8, opcode=4EB9 SR=2000
02098EC8: 4EB9 200A 246D jsr 0x200a246d.l
02098ECE: 4EF8 0000 jmp 0.w
02098ED2: 0001 0182 ori.b #0x82,d1
02098ED6: BE7C 0201 cmp.w #0x201,d7
02098EDA: 3C03 move.w d3,d6
ThisTask: 0x6FF56C00
68k register dump:
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00DFF000 246CFFEC 00000000 00000000 00000000 200A246D 021B6866 02098E6C
STCK: 00000003 20000209 8EC8200C 200A246C 02098ECE 02098F90 00000000 00000000
Dump of context at 0xEFB9B000
Trap type: Program exception
Machine State (raw): 0x00023032
Machine State (verbose): [Super] [FPU on] [IAT on] [DAT on] [Recoverable]
Temporary stack trace:
#0: in module Kickstart/kernel+0x00012F50 (0x01812F50)
#1: in module Kickstart/kernel+0x0004E06C (0x0184E06C)
#2: in module Kickstart/kernel+0x0005BD8C (0x0185BD8C)
#3: 0x20000209

Crashed task: compose.task (0x6FF56C00)
Program exception verbose description:
Trap instruction
IP points to excepting instruction
0: 0184E06C 02098E20 00000000 00000000 00000000 0000000C 00000002 00800000
8: 02071DB8 020A3990 00000000 020A3991 44224082 4DE4D7D0 00000010 02050000
16: 4DE4D868 000000EE 000002B7 02060000 00000001 020991B0 80000009 00DFF000
24: 8000000A 8000000E 8000000F 80000014 80000018 020A2AB4 021B6866 02098EC8
CR: 24224082 XER: 20000000 CTR: 0182D8C0 LR: 018279B0

FP0 : FFF8000082004000 406F400000000000 4068200000000000 0000000000000000
FP4 : 4042000000000000 4085B66660000000 40711CCCC0000000 0000000000000000
FP8 : 4042000000000000 4032000000000000 4085B66660000000 40711CCCC0000000
FP12: 408D880000000000 407AF00000000000 AC1BEF95D8E0FCDA 1C89478CC7EE6E5A
FP16: BC0B3D7577577BF8 B0AFEFCEF11DDEFF 7FF57BCEFF7AEC7B 3D76BBDF95B5FE39
FP20: BA1B9FAB5EE4AE43 FB185F2C155DFC16 3F4E03FA1DFA5EDC 6BB59FD0B6547DB2
FP24: 4071100000000000 4085B00000000000 3FF0000000000000 4042000000000000
FP28: 0000000000000000 4085B80000000000 406DC00000000000 4330000080000000
FPSCR: 82004000

Registers pointing to code:
r0 : module Kickstart/kernel at 0x0184E06C (section 0 @ 0x4E074)
r1 : module Kickstart/kernel at 0x02098E20 (section 1 @ 0x38E28)
r8 : module Kickstart/kernel at 0x02071DB8 (section 1 @ 0x11DC0)
r9 : module Kickstart/kernel at 0x020A3990 (section 1 @ 0x43998)
r11: module Kickstart/kernel at 0x020A3991 (section 1 @ 0x43999)
r15: module Kickstart/ATIRadeon.chip at 0x02050000 (section 2 @ 0x16A8)
r19: module Kickstart/kernel at 0x02060000 (section 1 @ 0x8)
r20: module Blitz3:Debug/REDDebugger at 0x00000001 (section 0 @ 0x0)
r21: module Kickstart/kernel at 0x020991B0 (section 1 @ 0x391B8)
r29: module Kickstart/kernel at 0x020A2AB4 (section 1 @ 0x42ABC)
r30: module Kickstart/kernel at 0x021B6866 (section 1 @ 0x15686E)
r31: module Kickstart/kernel at 0x02098EC8 (section 1 @ 0x38ED0)
ip : module Kickstart/kernel at 0x01812F50 (section 0 @ 0x12F58)
lr : module Kickstart/kernel at 0x018279B0 (section 0 @ 0x279B8)
ctr: module Kickstart/kernel at 0x0182D8C0 (section 0 @ 0x2D8C8)

Stack Backtrace:
(0x02098E20) module Kickstart/kernel at 0x01812F50 (section 0 @ 0x12F58)
(0x02098E30) module Kickstart/kernel at 0x0184E06C (section 0 @ 0x4E074)
(0x02098E50) module Kickstart/kernel at 0x0185BD8C (section 0 @ 0x5BD94)
(0x02098E6C)

Disassembly of crash site:
01812F40: 3C600180 lis r3,384
01812F44: 6063B5B4 ori r3,r3,46516
01812F48: 44000002 sc
01812F4C: 4E800020 blr
>01812F50: 7FE00008 trap
01812F54: 4E800020 blr
01812F58: 7C5343A6 mtsprg 3,r2
01812F5C: 3C400207 lis r2,519
01812F60: 604209F0 ori r2,r2,2544
01812F64: BC820010 stmw r4,16(r2)
Stack pointer (0x02098E20) is outside bounds
Redzone is OK (4)

68k register dump
DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
STCK: 0000FFFF 021B6866 0000FFFF 021B6866 0000FFFF 021B6866 0000FFFF 021B6866
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
STCK: 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C 0182F720 0182C25C
PC-8: 00108266 9F248266 9F030227 00006FF7 A2800000 00000181 2E200000 00000000
PC *: 00000000 00030000 05000000 F03001AC F0700000 00215E98 D8000000 00000000
68k IP (r21) "Kickstart/kernel" Hunk 0001 Offset 000391AE
68k IP ( r8) "Kickstart/kernel" Hunk 0001 Offset 00011DB8
----> 021B6866 - "Kickstart/kernel" Hunk 0001 Offset 00156866


Dump of context at 0xEF9BD3E0
Trap type: DSI exception
Machine State (raw): 0x0000F030
Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Temporary stack trace:
#0: in module Kickstart/kernel+0x0005EC2C (0x0185EC2C)
#1: 0xDB9A2F18

Crashed process: Blitz ][ Program Proc (0x47359B50)
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a store operation
0: FFFFFFFF 44D2DF94 25050750 600CCBA0 021B7220 6FFB8000 600CCBA0 600CCBE0
8: 44D8D314 000016D8 00084199 00000000 FFFFFFE6 44F4D000 00000000 00000001
16: 6FFFB000 600CCBA4 00000000 44D30D4E 52057050 44D8D314 600CCBC0 00000004
24: 00000004 0185EC08 00000664 80000007 6FFA8000 0000000C 02077C20 00000000
CR: 22000000 XER: 00000021 CTR: 0185EC08 LR: 01857118
DSISR: 42000000 DAR: 44F4D000

FP0 : FFF8000000000000 4084700000000000 4077600000000000 4330000080000000
FP4 : 0000000000000000 3FE0000000000000 7FF8000000000000 4057800000000000
FP8 : 40F0000000000000 4170000000000000 4C98E45E1DF3B015 33B011C2EAABE7D8
FP12: 408B380000000000 4079500000000000 AC1BEF95D8E0FCDA 1C89478CC7EE6E5A
FP16: BC0B3D7577577BF8 B0AFEFCEF11DDEFF 7FF57BCEFF7AEC7B 3D76BBDF95B5FE39
FP20: BA1B9FAB5EE4AE43 FB185F2C155DFC16 3F4E03FA1DFA5EDC 6BB59FD0B6547DB2
FP24: 6A3EDFEFFDC9EE9B BFD51DAE9DE2EEFF A54DF7CFE5DDDDE6 B61F4FEECFFEDEF1
FP28: 7F7BEEADCFD2D679 7C5A1BAE077CCCBF BC1EEBBE5E61EEBB 1F1001C38F7BFEF9
FPSCR: 00000000

Registers pointing to code:
r4 : module Kickstart/kernel at 0x021B7220 (section 1 @ 0x157228)
r15: module Blitz3:Debug/REDDebugger at 0x00000001 (section 0 @ 0x0)
r25: module Kickstart/kernel at 0x0185EC08 (section 0 @ 0x5EC10)
r30: module Kickstart/kernel at 0x02077C20 (section 1 @ 0x17C28)
ip : module Kickstart/kernel at 0x0185EC2C (section 0 @ 0x5EC34)
lr : module Kickstart/kernel at 0x01857118 (section 0 @ 0x57120)
ctr: module Kickstart/kernel at 0x0185EC08 (section 0 @ 0x5EC10)

Stack Backtrace:
(0x44D2DF94) module Kickstart/kernel at 0x0185EC2C (section 0 @ 0x5EC34)

Disassembly of crash site:
0185EC1C: 7DB6E92E stwx r13,r22,r29
0185EC20: 7C000774 extsb r0,r0
0185EC24: 553DCEFA rlwinm r29,r9,25,27,29
0185EC28: 7DB6E82E lwzx r13,r22,r29
>0185EC2C: 980D0000 stb r0,0(r13)
0185EC30: 2C800000 cmpwi cr1,r0,0
0185EC34: 39AD0001 addi r13,r13,1
0185EC38: 7DB6E92E stwx r13,r22,r29
0185EC3C: 4E800020 blr
0185EC40: 553D16FA rlwinm r29,r9,2,27,29
Stack pointer (0x44D2DF94) is inside bounds
Redzone is OK (4)

68k register dump - emulated code crashed
DATA: 44D30D4E 089A051A 00000000 113C880E 000493E0 FFD50001 6FFB4420 624C745A
ADDR: 44D5C479 44F21258 44D2DFDC 44F4D000 44D2DFE4 476BE270 6FD16684 44D2DF88
Page information:
Page not found
Last edited by Hypex on Wed Sep 18, 2013 2:56 pm, edited 1 time in total.
User avatar
gerograph
Posts: 95
Joined: Sun Mar 25, 2012 9:24 am
Location: Moers
Contact:

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

Post by gerograph »

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
User avatar
Hypex
Beta Tester
Beta Tester
Posts: 696
Joined: Mon Dec 20, 2010 2:23 pm
Location: Vic. Australia.

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

Post by Hypex »

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.
Post Reply