UAE debugger updates (executable debugging, segment tracking, symbols and more)

[Rock'n Roll]

debugmem_start=<address>
debugmem_size=<size in megabytes> Must be power of 2.

uaedbg <program to debug> <program parameters>

I change my A500 config to:
debugmem_start=0x60000
debugmem_size=0x1000 (2^12=4096=0x1000)

and start from shell >uaedbg example.exe

Shift+F12
Debugger answer is:
Failed to automatically allocate debugmem (no space)!
What I have to do?

[Toni Wilen]

It can't be used to move it over any existing memory space. It currently needs to at $7000000+ (won't work with 24-bit addressing)

Note that whole memory space becomes chipset accessible when debugmem is enabled.

[pipper]

@Toni

I uploaded an executable to AB3DII_fresh.zip

To test I created an A1200 setup with an 030 and 32MB of ZIII fastmem.

Under OS3.1 the executable crashes, but uaedbg is able to debug. You'll see illegal/uninitialized memory access during OpenWindowTagList that can be ignored. Later the executable seems to access invalid chipmem and in this situation I cannot break into the debugger again and I need to kill WinUAE.

Under OS 3.1.4 (3.2) the executable runs, but uaedbg is not able to debug... it will claim illegal instructions early on during startup of the executable, as if the debugger bungled the PC increment.

[pipper]

@Toni Wilen

Is the UAE debugger supposed to work with an emulated 060 CPU?

[Toni Wilen]

Originally Posted by pipper

Under OS3.1 the executable crashes, but uaedbg is able to debug. You'll see illegal/uninitialized memory access during OpenWindowTagList that can be ignored. Later the executable seems to access invalid chipmem and in this situation I cannot break into the debugger again and I need to kill WinUAE.

Debugger get stuck (in recent winuae versions) if debugger was entered at least once and then CPU goes in stopped state and there is no interrupt that can wake it up. (This is fixed in winuae.7z) Not sure if this is the problem.

Under OS 3.1.4 (3.2) the executable runs, but uaedbg is not able to debug... it will claim illegal instructions early on during startup of the executable, as if the debugger bungled the PC increment.

I haven't tried it with 3.1.4+ and probably won't too soon..

Originally Posted by pipper

@Toni Wilen

Is the UAE debugger supposed to work with an emulated 060 CPU?

CPU won't matter but other options might prevent it from working. More information needed. ("not working" don't help much).

[paraj]

Chip RAM "zero page" (0 to $400) is now watched (like Enforcer). All writes break to debugger immediately, long read from 4 is allowed, if vbr is 0: long aligned exception vector reads are allowed. All other reads break immediately.

Maybe dumb question, but didn't see it answered elsewhere in the thread. Am I supposed to move vbr if it's 0 on program start, and I want to setup my own interrupt handlers (e.g. level3) directly? The debugger breaks on the "illegal" write to $6c and then seems to ignore it (in debugmem_chipmem_lput) meaning the old interrupt handler still runs.
Tried it 4.9.0/4.9.1/4.9.2b2 with different configurations. Test exe+config attached just in case. Uaedbg is the one from post #1.

[Toni Wilen]

Only option currently is to move the VBR.

[paraj]

Originally Posted by Toni Wilen

Only option currently is to move the VBR.

Thanks, feature request then: Would be nice if it were handled by either amiga or pc side automatically so you don't have to change the executable you're testing.

[jotd]

Found out about this only now (well, I kind of knew something like this existed but never tried it before)

Works a treat, showing symbols & other features are just awesome compared to the crap way I had to debug stuff. Going to help a lot with my stalled projects!!

32-bit mode is required, as reminded several times, else it just fails without any explanation.

having the symbol printed is so noice:

70008190 [000188] 4ef9 7000 83f2           jmp $700083f2 xevious_reset

but then "f" command still asks for addresses. Isn't there a new debug command which can understand loaded symbols? I'd like to do

f xevious_reset

[pipper]

Originally Posted by paraj

Thanks, feature request then: Would be nice if it were handled by either amiga or pc side automatically so you don't have to change the executable you're testing.

You can use a tool like “vbrcontrol” on the Amiga side to move the VBR away from 0x00000000

[Toni Wilen]

Originally Posted by jotd

70008190 [000188] 4ef9 7000 83f2           jmp $700083f2 xevious_reset

but then "f" command still asks for addresses. Isn't there a new debug command which can understand loaded symbols? I'd like to do

f xevious_reset

f #xevious_reset should work. (without # it tries decode it as possible CPU register name and it does not have fallback)

[pipper]

Does the prefetcher cause Invalid Memory Access?
In this example it seems that the JMP instruction is directly adjacent
to uninitialized memory. But since we jump away from that address, the prefetcher is wrong and running into unallocated memory.

...
AllocMem ID= 140: 00000000 70e6d800 - 70e6d81d (30) AllocFlags: 00010001 PC: 00f820a0
....



Invalid access. Addr=70e6d81c RW=R Size=4: Accessing invalid memory
Page: 70e6d800 - 70e6d8ff. State=W Modified=*, Start=00, End=1D
  D0 00000000   D1 70E6D818   D2 00000000   D3 00000000
  D4 00000000   D5 00000000   D6 00000000   D7 00000000
  A0 00000000   A1 70E6D818   A2 00000000   A3 00000000
  A4 00000000   A5 00000000   A6 70E5C600   A7 70E5D6DC
USP  70E5D6DC ISP  400022A8 SFC  00000000 DFC  00000000
CACR 00002111 VBR  41FFFF00 CAAR 00000000 MSP  00000000
T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
SRP: 0 CRP: 0
TT0: 00000000 TT1: 00000000 TC: 00000000
Prefetch 70e6d81c deadf00d (1) 4018 (NEGX) dead (ADD) f00d (MMUOP030) Chip latch 00000000
70e6d818 4ef9 4018 19b6           jmp $401819b6
Next PC: 70e6d81e
>
>
>seg
Segment 1: 000003e9 70008000 - 700c2c5b (765020)
Segment 2: 000003ea 700cad00 - 700dc7ff (72448)
Segment 3: 000003eb 700e4800 - 70158c03 (476164)
Segment 4: 000003ea 70160d00 - 70160d87 (136)
Segment 5: 0000ffff 70168e00 - 70199b3f (200000) STACK
>d 70e6d818
70e6d818 4ef9 4018 19b6           jmp $401819b6
70e6d81e 9797                     sub.l d3,(a7) [00f9f86a]
70e6d820 9797                     sub.l d3,(a7) [00f9f86a]
70e6d822 9797                     sub.l d3,(a7) [00f9f86a]
70e6d824 9797                     sub.l d3,(a7) [00f9f86a]
70e6d826 9797                     sub.l d3,(a7) [00f9f86a]
70e6d828 9797                     sub.l d3,(a7) [00f9f86a]
70e6d82a 9797                     sub.l d3,(a7) [00f9f86a]
70e6d82c 9797                     sub.l d3,(a7) [00f9f86a]
70e6d82e 9797                     sub.l d3,(a7) [00f9f86a]

[pipper]

Another question: do the custom chips create memory violations like reading from 0 or reading from uninitialized memory?

[jotd]

I have started using it to debug one of my games.

I had to move some variables far from RTS of previous routines (else fake prefetch issue, ok)
I had to relocate VBR in fastmem and account for a relocated VBR: ok runs

But I get some spurious breaks, then game runs (practice). When moving to main event I get spurious interrupts again, and then I get a bus error (vector VBR+8 is called) at $7FFFFFFE apparently (from my game debug)

Running without uaedbg doesn't crash.

Zoned the exe & startup sequence. Using WinUAE 4.10.0

[Toni Wilen]

Originally Posted by pipper

Another question: do the custom chips create memory violations like reading from 0 or reading from uninitialized memory?

No. You can use debugger memwatch points do this partially.

Originally Posted by jotd

I have started using it to debug one of my games.

I had to move some variables far from RTS of previous routines (else fake prefetch issue, ok)
I had to relocate VBR in fastmem and account for a relocated VBR: ok runs

But I get some spurious breaks, then game runs (practice). When moving to main event I get spurious interrupts again, and then I get a bus error (vector VBR+8 is called) at $7FFFFFFE apparently (from my game debug)

Running without uaedbg doesn't crash.

Zoned the exe & startup sequence. Using WinUAE 4.10.0

Log messages probably would help. Fake bus error (generated if CPU jumps to non-existing address space) logging should have some extra info. If it is repeatable, set break point to bus error exception vector (whatever it points, usually it is ROM code) and use H to see history of CPU.

(I'll check files later)

[CFou!]

never tested, to do!
it seems really interesting

[jotd]

I think it needs some tuning, but the concept is really great. Enforcer sucks compared to this.

[Toni Wilen]

Originally Posted by jotd

Zoned the exe & startup sequence. Using WinUAE 4.10.0

I don't see any bus errors when using my usual config. Included config can't be used because 24-bit address space is too small, can't fit large enough debugger special memory space.

[jotd]

Can you start the game (press fire to skip the training part). The problem arose here. Training part were OK.

[Toni Wilen]

Originally Posted by jotd

Can you start the game (press fire to skip the training part). The problem arose here. Training part were OK.

When first screen appears, nothing happens, firebutton does nothing. Does it need some special config?