Øvelse+7+-+Debugging+on+host+and+cross+debugging+on+target

=Exercise 1 Debugging using gdb= Compile your application for the host, and single step through it using gdb.


 * Insert break points.


 * See the different threads.


 * Get a backtrace of the dierent threads and acknowledge what they are doing.

Finally introduce a //segmentation fault// and proceed to find it using gdb

//First we must enable core dumps, a core dump is a file dump of the appilcation at the time of its crash. To enable core dumps write this in the terminal:// code format="cpp" ulimit -c unlimited /*ulimit [Options] [Limit]*/

-c = The maximum size of core files created unlimited = No limit code

//For compiling the application to gdb:// code g++ -O0 -g -0 hello hello.cpp /*g++ [Options 1] [options 2] [Options 3] [File Output name] [File.cpp]*/

Options 1 = Optimizing command Options 2 = Add debug information code

//To start the application with gdb:// code gdb ./hello /*gdb ./[options]*/

options = application name code

//To insert a break point:// code b Thread1 /*b [Options]*/

Options = breakpoint code

//To see threads:// code /*Make a breakpoint*/ b Thread1 /*b [Options1]*/

Options1 = breakpoint

/*Run*/ r

/*See threads*/ Info Threads code

Make seg fault:

//If you see the pic, you can see we singel step through the program.//

=Exercise 2 Using ddd= New repeat Exercise 1 using ddd.

//It's basicly the same, but ddd is a GUI program where you have a intuitive control.//



//To set line numbers go to source and check out Display line number//

=Exercise 3 Cross debugging= Recompile the test application for target. Setup cross debugging via gdb, repeat and nd the error again.

//For compiling the application to the target:// code arm-angstrom-linux-gnueabi-g++ -g -o0 GDB.cpp -o hello -lpthread /*arm-angstrom-linux-gnueabi-g++ -g -o0 [options1] -o [options2] -lpthread*/

options1 = file to be compile options2 = application name code

//To start arm debugger:// code arm-angstrom-linux-gnueabi-gdb hello /*arm-angstrom-linux-gnueabi-gdb [options]*/

options = application name code

//Set shared library path for debugger(those residing on target):// code set solib-absolute-prefix /home/stud/setup-scripts/build/tmp-angstrom_2010_x-eglibc/sysroots/beagleboard/ code

//Connect to target(For the host):// code target remote: 10.9.8.2:1234 /*target remote: [options1]:[options2]*/

options1 = Target ip options2 = Port code

//Connect to host(For the taget):// code gdbserver localhost:1234 ./hello /*gdbserver localhost:[options1] ./[options2]*/

options1 = Port options2 = application name code

//The solib-absolute-prefix points to the root directory of the target on our host. The compiled stuff are installed into this directory on the host. Gdb use the// //solib-absolute-prefix whenever it needs to load a shared library, that means that if the application we are debugging depends on a library gdb will load the library symbols.//

=Exercise 4 Core dumps= Enable core-dumps on target and run the error prone program once again. Use the dumped core to nd the error in gdb on the host.

//To enable core dumps see exercise 1, to see core dumps://

//Load core dump in gdb:// code gdb ./hello core /*gdb ./[options] core*/

options = file to be compiled code

=Exercise 5 Cross debugging using ddd= New repeat Exercise 3 using ddd.

//To cross debugging using ddd is basicly the same as exercise 3. But to start debugging write:// code ddd --debugger hello /*ddd --debugger [options]*/

--debugger = tells the name of the debugger options = application name code

=Exercise 6 Valgrind & Hellgrind= Finally try to run the test application on the host using valgrind. How many memory leaks are actually in the program? Are there any thread issues?

Introduce at least 3 thread issues and see how the output re ects these changes. Similary introduce at least 2 dierent memory problems.

Explain the chosen problems and why they are important to understand.

// If you cannot imagine such a problem, how will ever find it? //

//To install valgrind:// code sudo apt-get install valgrind code

//To find memory leaks:// code valgrind --leak-check=yes ./hello /*valgrind --leak-check=yes ./[options]*/

options = application name code

//Most error messages look like the following, which describes problem 1, the heap block overrun: // code

24159
Invalid write of size 4

24159
at 0x80486AC: Thread3(void*) (GDB.cpp:18)

24159
by 0x4048D30: start_thread (pthread_create.c:304)

24159
by 0x421C46D: clone (clone.S:130)

24159
Address 0x0 is not stack'd, malloc'd or (recently) free'd

code //Things to notice://
 * //There is a lot of information in each error message; read it carefully. //
 * //The ==24159== is the process ID.//
 * //The first line "Invaild write" tells us what kind of error it is.//
 * //Below the first line is a stack trace telling you where the problem occurred. //

//Memory leak messages look like this:// code

24159
144 bytes in 1 blocks are possibly lost in loss record 1 of 1

24159
at 0x402732C: calloc (vg_replace_malloc.c:467)

24159
by 0x4010C34: allocate_dtv (dl-tls.c:300)

24159
by 0x40113D8: _dl_allocate_tls (dl-tls.c:464)

24159
by 0x404946C: pthread_create@@GLIBC_2.1 (allocatestack.c:571)

24159
by 0x8048718: main (GDB.cpp:28) code //Things to notice:// >>
 * There are several kinds of leaks; the two most important categories are:
 * //"definitely lost": your program is leaking memory -- fix it! //
 * "probably lost": your program is leaking memory, unless you're doing funny things with pointers (such as moving them to point to the middle of a heap block).