Linux has an incredible selection of tools for both debugging and profiling applications to get the most out of the system. In this session, we will start with gdb and show many of the lesser-known features that can significantly shorten debugging time. Next we will focus on the profiling and code coverage features found in gprof/gcov for determining both the performance of function calls and whether your test code is actually testing all of the code that it needs to test via examining the code coverage of the execution. Next, we will go into more sophisticated approaches using strace, ftrace, oprofile and LTTng and show how they work and why you might choose one over the other for certain tasks.
What we will talk about
GNU Project
Line debug levels
-ggdb3 debug infor for gdb more than COFF,XCOFF or DWARF2 fof -gExample
arm-linux-gnueabi-gcc -ggdb3 -o hello helloWorld.c
arm-linux-gnueabi-objdump -h hello
GDB GUI
GDB help
.gdbinit in current directoyuseful init
set history save on
set print pretty on
set pagination off
set confirm off
gdb -x load at load time
gdb has built in python interpreter Just call python.
Print table of how gdb will handle each signal:
info handle
Ways GDB can handle signla
handle signal keywords
signal SIGSEGV - deliver SEGV signal to the current program
watch -l <address/symbol> # command is scope aware
rwatch <a/s> # stops if read
watch <a/s> thread 3 # stops if thread 3 modified
watch <a/s> if <a/s> > 5 # stops when contents > 5
gdbserver 192.168.7.1:1929 myapp &
(gdb) target remote 192.168.7.2:1929
gdbserver hostIP:2345 –attach PID
watch system called made from user space.
strace -c ./capture_stream -D /dev/video0 -w 764*331 -p 1 | ./viewer -w 680*480 -p 1