Re: Hardcoded breakpoints vs. DDB

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Sat, Jun 07, 2008 at 08:17:23 +0400, Valeriy E. Ushakov wrote:

> I'm fixing sh3 ddb and I can't seem to wrap my head around how
> hardcoded breakpoints are supposed to be handled by DDB.
> 
> If there's a BKPT_INST already present in the text (and there's at
> least one such - the one in cpu_Debugger), how MD parts of DDB are
> supposed to tell it from the one inserted by DDB for a breakpoint?
> DDB restores real instructions at breakpoints only after MD code has
> run, so MD code cannot look at the instruction itself (it will always
> be BKPT_INST).
> 
> I gather those case -1 "keyboard interrupt" labels in kdb_trap are
> supposed to handle BKPT_INST in cpu_Debugger() and I guess some other
> means are used to distinguish it from dynamic breakpoints (instruction
> address?).
> 
> I don't see reasons to preclude hardcoded breakpoints.  While in C
> code you can always call cpu_Debugger(), in asm code it's easier to
> just add the breakpoint instruction instead of going through the
> hassle of calling a function (which can also ruin your neatly arranged
> register usage in a leaf routine).
> 
> For sh3 I can always use a different trap code so that hardcoded traps
> are not recognized as breakpoints, but that feels lie a kludge.
> 
> Can anyone comment on this?

On the second thought, the logic in db_stop_at_pc ("Now check for a
breakpoint at this address") seems to handle it.  I guess it might
failed for me b/c sh3 ddb was broken in other creative ways.

I will get back to it tomorrow, but meanwhile if someone has any
comments (esp. about that case -1) they are appreciated.

SY, Uwe
-- 
uwe%stderr.spb.ru@localhost                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen