Re: Using GDB with standalone assembly code questions

[Fernando Nasser <fnasser at cygnus dot com>]

David,

First of all, which compiler and which version of it have you used?
The exact compile line, with all switches is also necessary.

Then you should tell us which gdb (version, where did you get it etc.)
you are using.

Fernando


David J Croyle wrote:
> 
> 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

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299