Re: Howto single step from beginning

[Paul Blacquiere <blacq@slingshot.co.nz>]

> Check with "set debug target 1" before running to see
> what bytes it's inserting, then check your kernel sources (esp.
> arm/kernel/ptrace.c and arm/kernel/traps.c) to see which breakpoints
> it expects.

Ok, not sure how to interpret this:
------------------------------------
(gdb) run
Starting program: /home/blacq/src/bin/test
target_acknowledge_created_inferior (198)
   .
   .
   .
child:target_xfer_partial (2, (null), 0x1fc248,  0x0,  0x8094, 4) = 4, bytes =
00 e0 a0 e3
child:target_xfer_partial (2, (null), 0x0,  0x18c436,  0x8094, 4) = 4, bytes =
fe de ff e7
target_insert_breakpoint (0x8094, xxx) = 0
------------------------------------
So the first xfer, I assume retrieved the command at 0x08094, which is as per
the objdump.  the second xfer writes a 0x0e7ffdefe to 0x08094, which is an
undefined command.

Is my interpretation correct?

 From ptrace.c I find a comment as follows:
---
/*
  * New breakpoints - use an undefined instruction.  The ARM architecture
  * reference manual guarantees that the following instruction space
  * will produce an undefined instruction exception on all CPUs:
  *
  *  ARM:   xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx
  *  Thumb: 1101 1110 xxxx xxxx
  */
#define BREAKINST_ARM	0xe7f001f0
#define BREAKINST_THUMB	0xde01
---
If my interpretation on the gdb trace is correct, then it seems gdb is writing
an undefined instruction to generate an exception, but not the correct "user
instruction" to catch the registered hook?  But this part I am guessing.

Thanks

PaulB.