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

[sigma63]

Originally Posted by Toni Wilen

for example uae-configuration dbg "f 123456" to set break point.

Ah OK, that works! Thank you very much.

[alpine9000]

Should allocating chip ram with AllocMem work with this ?

When I run it through the debugger the chip ram allocations with AllocMem always return 0x0. Works fine outside the debugger.

(tested on 4.0.1)

[Toni Wilen]

Originally Posted by alpine9000

Should allocating chip ram with AllocMem work with this ?

When I run it through the debugger the chip ram allocations with AllocMem always return 0x0. Works fine outside the debugger.

(tested on 4.0.1)

Chip RAM allocations should fall back to original AllocMem()/AllocVec().

[alpine9000]

Originally Posted by Toni Wilen

Chip RAM allocations should fall back to original AllocMem()/AllocVec().

I wonder why the behaviour is different when the debugger is running. I have a small chip ram data hunk in the executable.

[Toni Wilen]

Originally Posted by alpine9000

I wonder why the behaviour is different when the debugger is running. I have a small chip ram data hunk in the executable.

Which is it? First you said AllocMem/AllocVec with MEMF_CHIP returns zero but now you talk about chip RAM hunks?

Chip RAM hunks are handled like it was using normal memory (they go to "debug ram") but extra emulator switch is activated that enables chip ram DMA to any RAM address.

If debugged program calls AllocMem/AllocVec (exec->ThisTask == debugged program), allocation comes from debug RAM except if MEMF_CHIP is set, which redirects call back to original function. (=invalid accesses are not detected)

MEMF_CHIP really should use separate "debug ram" region. Maybe later..

[alpine9000]

It’s both :-) the copper list is a chip hunk, everything else is allocated.

I’ll try getting rid of the chip ram hunk, but does this then means the chip ram allocations are not checked?

Edit: just re-read your reply. I think I’ll pre-allocate the chip ram as a hunk then run my own allocator on that ram, that way all accesses should still be checked.

[Bartman]

Hi Toni,
is the source code for uaedbg available? Currently working on GDB server for WinUAE and would like to customize the loader.

[Toni Wilen]

Originally Posted by Bartman

Hi Toni,
is the source code for uaedbg available? Currently working on GDB server for WinUAE and would like to customize the loader.

Source is now included with the archive (two binaries included, old and version that latest 4.2.0 requires due to ELF support)

But I don't think it will help, it is really minimal loader, loads the binary to RAM, sets up required DOS structures so that executable thinks it is running from CLI normally, move stack, the rest is done in winuae side.

[Bartman]

Thanks for the quick reply!

[Phantasm]

when i try to debug a program that opens a new screen it fails in the debugger.
eg. this in Amiga E works fine normally but fails when running in the debugger.



PROC main()
DEF sptr

sptr:=OpenS(640,256,3,0,'testscreen',NIL)
IF sptr=NIL THEN WriteF('openscreen failed\n') ELSE WriteF('openscreen success\n')
CloseS(sptr)
WriteF('done\n')
ENDPROC


I have attached the source and compiled exe

[Toni Wilen]

Chip RAM allocation fallback to normal chip ram is broken. This debugger mode does not yet support faking chip ram in "debug ram". Will be fixed in next version.

[Phantasm]

Originally Posted by Toni Wilen

Chip RAM allocation fallback to normal chip ram is broken. This debugger mode does not yet support faking chip ram in "debug ram". Will be fixed in next version.

Thats great, thanks.

[mcgeezer]

For some reason I can't seem to get this to play ball.

I'm using WinUAE 4.2.1 32 bit and my config is AGA with 4mb of chip ram.

I've allocated debug memory manually in the config file:

fastmem_options=start=70000000,end=6fffffff
debugmem_start=0x70000000
debugmem_size=512
mem25bit_size=0

When I run uaedbg test.exe I get this repeated.. constantly.

Trap #11: SR=0018 PC=7000800e Format=002c
Trap #11: SR=0018 PC=7000800e Format=002c
Trap #11: SR=0018 PC=7000800e Format=002c
Trap #11: SR=0018 PC=7000800e Format=002c
Trap #11: SR=0018 PC=7000800e Format=002c

What am I missing?

[Toni Wilen]

Does it work without debugmem config entries? Do you use console debugger? (GUI version won't work. xx switches.)

[mcgeezer]

Originally Posted by Toni Wilen

Does it work without debugmem config entries? Do you use console debugger? (GUI version won't work. xx switches.)

No, even if I remove fast ram or just add some (1mb) then all I get is

Failed to automatically allocate debugmem (no space)!

I always use the console debugger too.

[Toni Wilen]

Something is incompatible in your config. Make sure CPU is 32-bit addressing capable. "Too compatible" configs won't also work.

[mcgeezer]

Originally Posted by Toni Wilen

Something is incompatible in your config. Make sure CPU is 32-bit addressing capable. "Too compatible" configs won't also work.

Thanks Toni - Working now... I had 24 Bit addressing ticked.

This will be extremely useful!!!

[ross]

Hi Toni, a question about uninitialized memory complaints.

Is a part in a deploy/reloc system that construct a jump table:

AllocMem ID= 9: 00000000 7004b500 - 7004ca69 (5482) AllocFlags: 00000001 PC: 700089f4
Invalid access. Addr=7004c0a4 RW=R Size=4: Instruction fetch from uninitialized memory

Memory view:
7004C0A4 4ef9 7004 c106 JMP $7004c106

How I can make this a valid fetch for the debugger?

[Toni Wilen]

Originally Posted by ross

Hi Toni, a question about uninitialized memory complaints.

Is a part in a deploy/reloc system that construct a jump table:

AllocMem ID= 9: 00000000 7004b500 - 7004ca69 (5482) AllocFlags: 00000001 PC: 700089f4
Invalid access. Addr=7004c0a4 RW=R Size=4: Instruction fetch from uninitialized memory

Memory view:
7004C0A4 4ef9 7004 c106 JMP $7004c106

How I can make this a valid fetch for the debugger?

Any write access should have marked it as "initialized". How did you create this jump table instruction?

[ross]

Originally Posted by Toni Wilen

Any write access should have marked it as "initialized". How did you create this jump table instruction?

Something like this:

        MOVE.W	#$4EF9,(A0)+
	ADD.L	(A2)+,D0
	MOVE.L	D0,(A0)+

EDIT: debugger recognize the previous write but stop anyway
Page: 7004c000 - 7004c0ff. State=W Modified=*, Start=00, End=100