[hatari-devel] Catching trap exit?

[Eero Tamminen]

Hi,

On Monday 18 October 2010, Nicolas Pomarède wrote:
> This approach could be made more generic and not limited to trap.

Using disasm didn't work very well because in some cases it can
constantly output stuff on traps (for which one currently doesn't
have matching breakpoints or isn't otherwise interested).

I looked into modifying UAE CPU disassembly code to avoid this, but it was
printing things in several places, so I though to wait for Markus'
disassembly code and hope that it would have a separate function for asking
about next PC address.

Markus, could you post your code?


> By 
> using this method, you can have a more "intelligent" step function for
> the debugger (as available under monst for instance) :
>   - you can have a simple step instruction that breaks each time PC is
> changed

Do you mean shortcut for:
	b pc ! "pc" :once
or for:
	c 1
debugger command?


>   - 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?

If yes, then a shortcut for this is enough:
	b pc > "pc" && pc < "pc <maxlen + 1>" :once


> Some disassembler used "s" and "z" shortcuts (or "t" for trace) to
> differenciate these 2 behaviours.
>
> (Note that Vincent's idea of getting the return from 2(sp) is also a
> valid one ; but to intercept any kind of branch opcodes you need to get
> return pc from 2(a7) if this in an exception handler (trap, ...) or from
> (a7) if this is a "normal" branch (bsr, jsr, ...), so slighlty more
> cases to handle)

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?


	- Eero