Re: [ECOS] Question about hal stub debugging support. Thanks a lot.

[Gary Thomas <gary at mlbassoc dot com>]

On Sun, 2003-08-03 at 04:35, jameshq@liverpool.ac.uk wrote:
> Hi all:
>    I am trying to adding debugging support for a new target, I come
> across some question. I hope somebody can give me idea. thanks a lot.
> In file "arm_stub.c"  function "__single_step()"
> 
> // Decode instruction to decide what the next PC will be
> ss_saved_pc = (unsigned long) target_ins((unsigned long*)pc, curins);
> 
> why does here need to call "target_ins()" for decoding next
> instruction? Isn't that just the next instruction follows the current
> one? (what's for decoding?) 
> for example:
> 
> Instruction #1:     mov r0,#10 
> Instruction #2:     mov r1,r0
> 
> if currently breakpointed at instruction #1 and next instruction is
> #2, so why does "target_ins()" called for decoding the next
> instruction, (isn't that just "mov r1,r0" ? can't we just return
> this?)
> 
> I may misunderstand this, hope anybody can help me out. Thanks a lot
> 

But what about if the instruction sequence is:
  bl _some_fun
  mov r0,#10

In this case, the next instruction to execute will be the first one
in the function "_some_fun"

Since the ARM hardware does not support the notion of single-step
in the CPU (some other processors can do this), we have to figure out
where the next actual instruction to execute will be and put a
temporary breakpoint there - thus the function "target_ins()"
Of course, it's even more complicated if the current instruction is
conditional, e.g.
  bleq _some_fun

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss