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

[Toni Wilen]

I guess I forgot to make it less strict when I decided to make this more usable for generic debugging..

But cache "support" is good idea: next update will complain if address was modified and later it gets executed without cache flush (if 68020+).

[ross]

Originally Posted by Toni Wilen

I guess I forgot to make it less strict when I decided to make this more usable for generic debugging..

But cache "support" is good idea: next update will complain if address was modified and later it gets executed without cache flush (if 68020+).

Thanks!

[rikkles]

Using W on the debugger, it's not possible to write a string with spaces. I'm forced to write hex. Am I missing something?

[Toni Wilen]

Originally Posted by rikkles

Using W on the debugger, it's not possible to write a string with spaces. I'm forced to write hex. Am I missing something?

W command line parsing uses normal parsing/get next character functions that automatically strips white space.. Oops, will be fixed

[rikkles]

Thanks! Helps having to convert manually

[mcgeezer]

@toni - I've had time today to try out the uaedbg side loader and new printf functionality in 4.4.0.

On the uaedbg, I'm finding the debugger is breaking on instruction fetch changes.

Configuration is A1200 with Cycle exact, here's my code snippet:

agdPingPong:
	tst.l	.dir
	beq.s	.down
	bmi.s	.up		
	bra.s	.exit

.down:	cmp.w	#$8c,CAMERA_YPOS
	beq.s	.swap
	bsr	agdPanDown
	bra	.exit

.up:	cmp.w	#$0,CAMERA_YPOS
	beq.s	.swap
	bsr	agdPanUp
	bra	.exit
	
.swap:	not.l	.dir
	bra.s	.exit
	
.dir:	dc.l	0

.exit:	rts

As you can see I'm using local/private variables in the code.

Whenever the not.l is executed the debugger is breaking with:

Invalid access. Addr=7000968c RW=R Size=4: Instruction fetch from memory that was modified after being executed at least once

Is there a valid reason the debugger is breaking due to this? If I was to guess what was happening I'd say the cache is being loaded and then the code is changing the value in memory causing it to break - but I'm not self modding the code.

Is there any way to disable this particular check if what I think is happening is correct?

Cheers,
Graeme

[Toni Wilen]

Instruction prefetch read hits the variable address. Either it happens when branch is executed (branch + next word/long gets loaded depending on alignment) or when jumping to RTS and RTS address is not long aligned (prefetch would load low word of variable and opcode of RTS)

It can't know if it is self-modifying code or just a harmless side-effect.

Keep variables further away from code. (I personally prefer using A4 or A5 as a base pointer to variables, I hate unnecessary absolute addresses )

There is no option to disable kit, at least not yet.

[mcgeezer]

Originally Posted by Toni Wilen

Instruction prefetch read hits the variable address. Either it happens when branch is executed (branch + next word/long gets loaded depending on alignment) or when jumping to RTS and RTS address is not long aligned (prefetch would load low word of variable and opcode of RTS)

It can't know if it is self-modifying code or just a harmless side-effect.

Keep variables further away from code. (I personally prefer using A4 or A5 as a base pointer to variables, I hate unnecessary absolute addresses )

There is no option to disable kit, at least not yet.

Thanks for the explanation Toni.

I've put in some nops (CNOP 0,16 in Vasm) before the variable and now the debugger is not breaking which is good. While I do point one of the address registers to my global variables I also like the convenience of using local labels because then I don't need to have them as unique names in the global space. I'll make do with the workaround I have.

Thanks for the fast response.

[Docent]

Is this tool still available for download? I got error 403 trying to access the link from 1st message.

[DamienD]

Originally Posted by Docent

Is this tool still available for download? I got error 403 trying to access the link from 1st message.

Here you go:

https://download.abime.net/winuae/files/b/uaedbg.zip

[DamienD]

@Toni, you may want to update the 1st post of this thread with the above

[Toni Wilen]

Changed but replacing old url http->https should have been enough to fix it. I'll need to ask RCK again.

[Docent]

Originally Posted by DamienD

Here you go:

https://download.abime.net/winuae/files/b/uaedbg.zip

Thanks, Damien!

[Docent]

Hi Toni,
Is this possible to implement support for SAS C HUNK_DEBUG? I found only some info here about the content of this hunk when compiling with debug=line, but even that would be great to have.

[phx]

Originally Posted by Toni Wilen

- Does other popular compilers also generate useful HUNK_DEBUG

As Docent already mentioned: the most common format under Amiga compilers and assemblers is the LINE debug block from SAS/C. Should be trivial to implement.
As a bonus maybe also HCLN from Devpac.

[Toni Wilen]

Few example executables + source files required. Standard requirement

[pipper]

When running an executable under uadbg, I'm getting illegal instruction exceptions early on. When I look at the code/data, it looks like as if the data matches the executable, but PC somehow ended up "inside" instructions. This does not happen when running the executable under regular circumstances.

I tried with "more compatible" on and off, both same results.

I'm emulating an A1200 + Blizzard1230 IV + 64MB (MMU enabled, MMULib in use)

Do you have any advice on what went wrong?

[pipper]

Are BSS segments recognized as "uninitialized"? If so, they probably should not.

Edit: the uninitalized reads were pointing to (chip) memory that had been allocated without MEMF_CLEAR. This happened when calling OpenWindow, so out of my control.
Is there a way to only get exceptions "Invalid access. Addr=702da24c RW=R Size=4: Reading uninitialized memory" for memory that has not been allocated?

[pipper]

Are BSS segments recognized as "uninitialized"? If so, they probably should not.

Edit: the uninitalized reads were pointing to (chip) memory that had been allocated without MEMF_CLEAR. This happened when calling OpenWindow, so out of my control.
Is there a way to only get exceptions of kind "Invalid access. Addr=702da24c RW=R Size=4: Reading uninitialized memory" for memory that has truly not been allocated?

[Toni Wilen]

This happened when calling OpenWindow, so out of my control.

It is still a bug somewhere. Possibly bad parameters to some OS call or some other corruption. You need to solve this problem first.

When running an executable under uadbg, I'm getting illegal instruction exceptions early on. When I look at the code/data, it looks like as if the data matches the executable, but PC somehow ended up "inside" instructions

Examples please. Instruction caches or MMU can cause side-effects.