Howto single step from beginning

Howto single step from beginning

[Paul Blacquiere]

Hi,

Please forgive the elementary question, but I can't find the answer.

I would like to be able to SI from step 1, but this would result in an error -
"The program is nor being run"

The obvious solution which does not work, is to set a break point at the address
before the one I am really interested in, however no break at this address is
done, and instead the program runs on through.

Thanks in advance


PaulB.

Re: Howto single step from beginning

[Daniel Jacobowitz]

On Thu, Feb 02, 2006 at 02:08:31PM +1300, Paul Blacquiere wrote:
> Hi,
> 
> Please forgive the elementary question, but I can't find the answer.
> 
> I would like to be able to SI from step 1, but this would result in an error -
> "The program is nor being run"

There's no command to do this today.  We've been discussing adding one.

> The obvious solution which does not work, is to set a break point at the address
> before the one I am really interested in, however no break at this address is
> done, and instead the program runs on through.

Sorry, but I don't understand what you mean.  You'd have to show a
complete example.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Howto single step from beginning

[Paul Blacquiere]

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.

Re: Howto single step from beginning

[Daniel Jacobowitz]

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

Re: Howto single step from beginning

[Paul Blacquiere]

> 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.

pretty sure it is static
gcc -g --static -o test test.c

result as follows:
-------------------------------
(gdb) set stop-on-solib-events 1
(gdb) run
Starting program: /home/blacq/src/bin/test

Program received signal SIGILL, Illegal instruction.
0x00008094 in _start ()
(gdb)
------------------------------

>
> Secondly, does it work outside of GDB?

Yup, sorry forgot to mention earlier.

> 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.
>

Your description seems very feasible, as I am using Linux kernel 2.6.12.

I will investigate this further.

PaulB.

Re: Howto single step from beginning

[Paul Blacquiere]

> 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.

Re: Howto single step from beginning

[Daniel Jacobowitz]

On Thu, Feb 02, 2006 at 05:45:00PM +1300, Paul Blacquiere wrote:
> 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

Remind me again what version of GDB you're using?  And it is configured
for arm-linux, right?  Or maybe you're debugging a uClibc static binary
that doesn't have the correct ABI markings?

That's an arm-elf breakpoint.  It doesn't work on arm-linux systems.

Does "show osabi" reveal anything?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Howto single step from beginning

[Paul Blacquiere]

>
> Remind me again what version of GDB you're using?  And it is configured
> for arm-linux, right?  Or maybe you're debugging a uClibc static binary
> that doesn't have the correct ABI markings?

GDB Ver 6.3 build under buildroot using uCLibc

>
> That's an arm-elf breakpoint.  It doesn't work on arm-linux systems.
>
> Does "show osabi" reveal anything?
>
----
(gdb) show osabi
The current OS ABI is "auto" (currently "ARM APCS").
The default OS ABI is "GNU/Linux".
(gdb)
----

I am assuming that the ABI markings are involved in the definition of 
the break
point instruction, as I can not find a corresponding match to the gdb trace
instruction in the gdb source.

PaulB.

Re: Howto single step from beginning

[Daniel Jacobowitz]

On Thu, Feb 02, 2006 at 06:29:05PM +1300, Paul Blacquiere wrote:
> >
> >Remind me again what version of GDB you're using?  And it is configured
> >for arm-linux, right?  Or maybe you're debugging a uClibc static binary
> >that doesn't have the correct ABI markings?
> 
> GDB Ver 6.3 build under buildroot using uCLibc

That's why.  Some versions of uClibc do not include a Linux ABI marker;
see what "objdump -s -j .note.ABI-tag" on the static binary you are
debugging shows.  I think this has been fixed.

> >That's an arm-elf breakpoint.  It doesn't work on arm-linux systems.
> >
> >Does "show osabi" reveal anything?
> >
> ----
> (gdb) show osabi
> The current OS ABI is "auto" (currently "ARM APCS").
> The default OS ABI is "GNU/Linux".
> (gdb)
> ----

Also GDB 6.3 would erroneously override the default ABI, as you see
here.  Try 6.4 instead.

> I am assuming that the ABI markings are involved in the definition of 
> the break
> point instruction, as I can not find a corresponding match to the gdb trace
> instruction in the gdb source.

Look for ARM_BE_BREAKPOINT in arm-tdep.c.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Howto single step from beginning

[Paul Blacquiere]

>
> That's why.  Some versions of uClibc do not include a Linux ABI marker;
> see what "objdump -s -j .note.ABI-tag" on the static binary you are
> debugging shows.  I think this has been fixed.
>

Correct, I downloaded and installed the latest snapshot (02/02/06), and it all
works.

Thanks a heap..