This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Howto single step from beginning



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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]