Using GDB with standalone assembly code questions

[David J Croyle <dcroyle at telerama dot com>]

Hello all!

We are trying to debug/verify a very simple ARM assembly language
program
and we hoped to use the gdb ARM simulator w/ddd as the frontend though
we
have encountered a few issues.

Our goal is to single step through the code and watch the registers
change
(and perhaps observe memory locations/memory mapped registers) but gdb
seems some what intent on not simulating our code.

We use the following sequence to "get gdb going":

(Load an ARM executable into gdb via DDD Open Program under File):

(gdb) file testarmasm.exec
warning: arm architecture file may be incompatible with armv4 target.
Reading symbols from
testarmasm.exec
(no debugging symbols found)...done.

We then issued these commands to gdb by hand:

(gdb) target sim
Connected to the simulator.
(gdb) set language asm
(gdb) load
Loading section .text, size 0x124 vma 0x0
Start address 0x0
Transfer rate: 2336 bits in <1 sec.

However when we issue the step command the response is:

(gdb) step
Single stepping until exit from function _start, 
which has no line number information.
The program is not being run

Our registers don't change and neither does the program counter.

When we issue "run" gdb seems to get stuck in a never ending loop (the
registers which we have told ddd to display do not change) and the green
light just keeps blinking.

If we interrupt gdb and start the whole process over (reload the
executable, issue target sim, etc.) and use the "go" command and specify
a
label from our code such as ledon23(a valid label) our response is:

(gdb) go ledon23
Breakpoint 1 at 0xa8
Continuing at 0xa8.
The program is not being run.
(gdb) 

We then see the program counter pointing to 0xa8 but issuing "run"
either
locks gdb or if we stop the run almost imediatly with control-c, we can
see that a few registers changed though the run/interruption cannot be
done with any hopes of reliability. 

It is interesting to note that while gdb mentions it did not find any
debug symbols, it does know of the labels we used in our ASM program
meaning it has read that information successfully from our executable.

In addition to the run/control-c, we can issue a "b <label>" and gdb
will
set the breakpoint at the correct label (the address was verified by
looking out our .lst file). However we still do not have the ability to
single step/step into the next instruction.

An "info watchpoints" shows all our breakpoints with the correct labels.

Are there any suggestions on how we can single step through our code or
execute our "pure ASM" program and observe registers and such?

We've built gdb for target=strongarm-elf on a i686-pc-linux-gnu host.
We've told ddd to use our strongarm built gdb by using the --debugger
switch on ddd start-up.

Our ARM executable was built on this same machine, cross-compiled by
using
a cross toolchain we built to produce standalone ARM executables (we
used
newlib headers instead of glibc but since this is "pure ASM" program
that
should not matter).

Thanks in advance, 
Dave & Vasant.





David J. Croyle
EE / Software Developer
Foerster Instruments, Inc.
Windows e-mail: dcroyle@foerstergroup.com
  Linux e-mail: dcroyle@telerama.com