Vendor SDK provides a 'gdb' and 'gdbserver' tools. See the last section in 'sn9866_series_linux_environment_user_guide_v1_00.pdf' documents for more information.

The version of 'gcc' provided by vendor SDK is '4.5.2'. This version supports an output of debug information in formats 'dwarf' up to 'dwarf-4' and 'stabs'.

The version of 'gdb' and 'gdbserver' is '6.8'. This version supports an output of debug information in formats 'dwarf' up to 'dwarf-2' and 'stabs'.

When debugging programs written in pure C you are free to choose any format supported by both compiler and debugger. In this case it enough just to add '-g' option to CFLAGS and LDFLAGS. By default it enables 'dwarf-2' format. In order to choose different format use instead '-gdwarf-4' or '-gstabs' for example.

Troubles arise when you want to debug a C++ programs that contain non-POD C++ classes or namespaces. To be a non-POD (POD stands for plain old data) C++ class should contains for example an explicit constructor. The issue is that DWARF-2 does not support C++ namespaces. Support for C++ namespaces was first added in DWARF-3 format. However, to compile program with '-gdwarf-3' does not solve the issue because vendor's 'gdb' does not support this format. The actual solution is to compile and link C++ programs with '-gstabs+' flag. '-gstabs+' enables 'stabs' format plus some GNU-specific extensions which are incompatible with others debuggers but may be helpful when dealing with gdb.

Suppose your program is called 'rtsp_server' and it should be executed with arguments '-W 640 -H 480 -Q 10 -b 4096 -a'. Suppose you have a local copy of your target's root filesystem in '~/sdk/rootfs' directory on the host machine and toolchan in '~/sdk/toolchain' directory. In order to debug program from the remote host machine you should start gdbserver on the target machine:

# gdbserver :2000 rtsp_server -W 640 -H 480 -Q 10 -b 4096 -a

run gdb on the host side and connect to the target:

$ export PATH="~/sdk/toolchain/bin:$PATH"
$ arm-linux-gdb --args rtsp_server -W 640 -H 480 -Q 10 -b 4096 -a
> set sysroot '~/sdk/rootfs'
> target remote 192.168.1.101:2000
> breakpoint main.cc:main
> continue

One can automate previous steps by creating gdb init script file called '.gdbinit' in the current (working) directory on the host side:

$ cat > .gdbinit <<-EOF 
set sysroot '~/sdk/rootfs'
target remote 192.168.1.101:2000
continue
EOF