[hatari-devel] Catching trap exit?

[Eero Tamminen]

Hi,

On Tuesday 19 October 2010, Nicolas Pomarède wrote:
> > Do you mean shortcut for:
> > 	b pc ! "pc" :once
> > or for:
> > 	c 1
> > debugger command?
>
> this should be for the case where you execute one opcode at (pc) then
> stop, so I think it's more for "c 1"
>
> Your 1st example would not work for the following code :
>
> 	move	#1567,d0
> .loop	dbf	d0,loop
>
> When pc = .loop, you will execute 1568 dbf, but pc won't change (from
> the point of view of the debugger, it will change at the 68000 level),
> so I think your 1set example will only break after the last dbf ?

Yes.  I wasn't sure which one you were asking for. :-)


> I think the correst "step" command should be the one that breaks 1568
> times.

Do you think "c 1" really needs a shortcut?


> >>    - you can have a more elaborate step instruction that breaks after
> >> opcodes that changes PC by jumping elsewhere. This is handy to execute
> >> a sub routine / trap handler as a whole, without going step by step in
> >> the routine.
> >
> > Is the longest such instruction shorter than shortest such instruction?
>
> ?? Sorry, I don't understand what is "such instruction" ?
>
> > If yes, then a shortcut for this is enough:
> > 	b pc>  "pc"&&  pc<  "pc<maxlen + 1>" :once

This would would also need special case for rt[drs] instructions where
it would do just:
	pc ! "pc" :once


> what is maxlen ? If it's the maximum size of a branch instruction, then
> it won't work the way you propose.
>
> jsr $123456.l will take 6 bytes
> trap / bsr.s will take 2 bytes

Ok, so it will really need to know the instruction length.

-> Will need to wait Markus' code and it (hopefully) providing
    a function for this...

I guess breakpoints will then also need some flag to silence the normal
output from breakpoint matching as that could be annoying. :-)


> > I quickly looked at these values but they didn't seem to match the next
> > instruction address so I guess I was doing something wrong.  How you
> > would get that value in Hatari C-code?
>
> Have a look at m68k_do_rts in cpuemu.h :
> m68k_setpc(get_long(m68k_areg(regs, 7)));
>
> so get_long(m68k_areg(regs, 7)) is what you need to return from a non
> exception branch (for exceptions, return pc is at 2(a7), so
> get_long(m68k_areg(regs, 7)+2) will do the trick)

On the Hatari side that should be:
	STMemory_ReadLong(Regs[REG_A7]+2)

Which I've already tried.  However, it doesn't give the same value as what
the UAE disassembly function gives as next value.

When there's a VDI exception, I get:
next PC: $fe5bcc
(sp): $fe1f1a
2(sp): $1f1a000c

And for Bios exceptions which have the opcode in stack, I get (for example):
next PC: $fc9260
(sp): $70000
2(sp): $0

Debugger is called at the end of newcpu.c::do_specialties() which seems
to happen before the exception handling in AUE core.  At this point D0
is at least OK, but could it affect what's on the stack?


	- Eero