Hi,

Yeah you are right that GDB is doing the write of undefined instruction 
when it discover that our gdb-stub doesn't handle Z0 (breakpoint).
But then when it continue past a breakpoint or gdb issue a 's' (single 
step command) our gdb-stub needs to handle a single step. It's actually 
very close from doing that. This can be fixed either by apply the patch 
I provided in the first post or something more elaborated, like to have 
db_set_single_step() differ if we are calling from ddb or kgdb?

Regards.


Hiroyuki Bessho wrote:
> At Tue, 29 Mar 2005 23:25:44 +0200,
> Karl Janmar wrote:
> 
>>Hi,
>>
>>I have double checked now, I don't have DDB defined, and I think I can
>>trace the whole path to where
>>KERNEL_BREAKPOINT is incorrectly written.
>>
>>sys/kern/kgdb_stub.c:kgdb_trap() ---->
>>sys/ddb/db_run.c:db_set_single_step() ---->
>>sys/arch/arm/include/db_machdep.h:BKPT_SET()
>>
>>hmm...  I don't see where the DDB define matter anyway, since the
>>BKPT_SET() macro is always using KERNEL_BREAKPOINT that is define
>>without any ifdefs that changed depending on debugging method?
>>
> 
> 
>   Mmm, I misunderstood the code.  You are right and
> db_set_single_step() is not #ifdef-ed out by DDB.
> 
>   IIRC, gdb sets break point by itself using read/write command
> through stub, so kernel doesn't need to put GDB breakpoints
> (db_set_single_step is not called in KGDB).  At least, it was the way
> it worked when I used KGDB last time.  It seems gdb is using step
> command and the kernel is required to put GDB breakpoint by itself in
> Karl's case.  GDB or stub have changed or Karl is using different
> version of GDB?
> 
>   I'll try kgdb on an eval board tonight.
> 
> Thank you,
> 
> bsh.