Re: Howto single step from beginning

Daniel Jacobowitz
2006-02-02T02:57:09Z

On Thu, Feb 02, 2006 at 03:52:52PM +1300, Paul Blacquiere wrote:
> Hi,
>
> >Sorry, but I don't understand what you mean. You'd have to show a
> >complete example.
>
> This is the beginning of the prog to debug (ARM) :
>
> 00008090 <_start>:
> 8090: e3a0b000 mov fp, #0 ; 0x0
> 8094: e3a0e000 mov lr, #0 ; 0x0
> 8098: e49d1004 ldr r1, [sp], #4
> 809c: e1a0200d mov r2, sp
> 80a0: e52d2004 str r2, [sp, #-4]!
> 80a4: e52d0004 str r0, [sp, #-4]!
>
>
> start gdb:
> $> gdb test
>
> attempt to run:
> --------------------------------
> (gdb) run
> Starting program: /home/blacq/src/bin/test
>
> Program received signal SIGILL, Illegal instruction.
> 0x00008094 in _start ()
> (gdb)
> --------------------------------
> (by now you are muttering, not this old chestnut again...)
>
> So I would like to investigate the CPSR etc before and after, as the command
> (mov lr, #0 ; 0x0) looks good to me.
>
> trying the following:
> --------------------------------
> (gdb) break _start
> Breakpoint 1 at 0x8090
> (gdb) run
> Starting program: /home/blacq/src/bin/test
>
> Program received signal SIGILL, Illegal instruction.
> 0x00008094 in _start ()
> (gdb)
> --------------------------------
>
> So at this point I am stumped.

OK, I've got two things for you.

First, assuming that this is a dynamically linked application, try
"set stop-on-solib-events 1". That'll stop you way back in the dynamic
linker. From there you may be able to single-step to _start; it gets
called from something like _dl_start_user.

Secondly, does it work outside of GDB? If so, I'd suspect that the
breakpoint GDB has invisibly placed at _start (which it always does)
is causing SIGILL instead of SIGTRAP. There was some change in this
area for ARM/Linux recently. If your kernel is too old, perhaps
GDB is using a breakpoint that it doesn't support. Or maybe it's GDB
that's too old. 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.

--
Daniel Jacobowitz
CodeSourcery