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.