That's enough to get you around a bit. '''help''' will get you information about more commands. '''c''' will continue from where you stopped.

That's enough to get you around a bit. '''help''' will get you information about more commands. '''c''' will continue from where you stopped.

+

+

Try this:

+

<pre>

+

gdb cfft_arm

+

gdb) b fft_exec

+

(gdb) r

+

(gdb) n 4

+

(gdb) l

+

(gdb) p n

+

</pre>

+

We're in the '''fft_exec''' routine and have '''n'''ext'ed a in a way and then printed the value of '''n'''. The '''main''' routine also has an '''n''', how do we see it's value? It's on another stack frame, so do a backtrace to see what's on the stack and then select the frame we want.

+

<pre>

+

(gdb) bt

+

#0 fft_exec (N=16, in=0x12090) at cfft.c:80

+

#1 0x0000865c in main () at main_cfft.c:62

+

(gdb) f 1

+

#1 0x0000865c in main () at main_cfft.c:62

+

62 fft_exec (N, out);

+

(gdb) p n

+

$7 = <value optimized out>

+

(gdb) f 0

+

#0 fft_exec (N=16, in=0x12090) at cfft.c:80

+

80 for (k = 0; k < i; k++)

+

(gdb) p n

+

$8 = 16

+

</pre>

+

The '''f''' command selects the frame we want to inspect. Notice in this case the value of '''n''' in '''main''' has been ''optimized out'', that means the compiler found a way to compile the code that didn't need to put '''n''' on the stack. In the '''Makefile''' you will find the '''-O3''' option will tells the compiler to optimize a lot. Try removed the '''-O3''' and remaking everything and seeing if '''n''' appears in '''main'''.

Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

The program being debugged can be written in Ada, C, C++, Objective-C, Pascal (and many other languages). Those programs might be executing on the same machine as GDB (native) or on another machine (remote). GDB can run on most popular UNIX and Microsoft Windows variants.

For our lab we'll be using a C program and do both local execution on the BeagleBoard and remote execution with gdb running on your host and debugging code on your Beagle.

Edit the Makefile and correct ARM_TOOLCHAIN_PATH for your machine. Also search for install: and fix it for your beagle.

$ make all install

This will compile the code and scp to your Beagle. You've just compiled a program that performs a complex fft on random data. It's main purpose is to see how fast it runs on the Beagle. (In case you are interested, I added to rule so you can compile it for your host computer. Try make x86 and compare the times on your host to those on the Beagle.)

The program takes several seconds to run on the Beagle, so you may want to edit the code so it doesn't run so many iterations.

When first starting gdb notice the line This GDB was configured as "arm-angstrom-linux-gnueabi. This is a good sign. The first command b main sets a breakpoint at main. The next command runs to that break point. Now lets look at our code a this point. Try the list command.

(gdb) l
1 /home/yoder/BeagleBoard/oe/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/glibc-2.9-r36.3/build-arm-angstrom-linux-gnueabi/csu/crtn.S: No such file or directory.
in /home/yoder/BeagleBoard/oe/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/glibc-2.9-r36.3/build-arm-angstrom-linux-gnueabi/csu/crtn.S
(gdb) quit

Hmmm.... We have a problem. For gdb to be most useful we need to tell gcc to include debugging information. Back to your host computer and edit the Makefile and find ARM_CFLAGS and add -g. The line should look like:

That's enough to get you around a bit. help will get you information about more commands. c will continue from where you stopped.

Try this:

gdb cfft_arm
gdb) b fft_exec
(gdb) r
(gdb) n 4
(gdb) l
(gdb) p n

We're in the fft_exec routine and have next'ed a in a way and then printed the value of n. The main routine also has an n, how do we see it's value? It's on another stack frame, so do a backtrace to see what's on the stack and then select the frame we want.

The f command selects the frame we want to inspect. Notice in this case the value of n in main has been optimized out, that means the compiler found a way to compile the code that didn't need to put n on the stack. In the Makefile you will find the -O3 option will tells the compiler to optimize a lot. Try removed the -O3 and remaking everything and seeing if n appears in main.