Re: Howto single step from beginning

[Daniel Jacobowitz <drow@false.org>]

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