gdb on arm-linux

It is a little different to debug an application on arm-linux.

First, start gdbserver from the device, 3230 is any port number that is not used by the network.

gdbserver localhost:3230 ./helloworld

Second, start arm-linux-debug from the host,

arm-linux-gdb ./helloworld
target remote 10.10.10.20:3230
b main
c

Here b identify set break point, and c identify continue, they are gdb commands.

Right now, I am debugging without emacs, still hope to configure emacs to support embedded debugging.

gdb - c++ on the virtual class

Sometimes I feel I waste a lot of time stuck in one single point. If I have a class IFoo, it is just an abstract interface, so it defines foo function but never implements it. The implementation of foo was in the concreate classes, such as CFooConcreateA and CFooConcreateB. The problem of gdb is, if I use a pointer to IFoo, as "IFoo* pFoo", gdb only reports the type of pFoo is IFoo, I have no way to get the real concreate object by pFoo, so if i do "print *pFoo", gdb will response with "incomplete type". I search the internet, read gdb manual again and again, even read gdbinit macro about QString, still no help (QString contains a 'd' to store the string data which is different than IFoo). Am I something wrong, learning gdb not enough, or there is really no way to figure it out.

The only way right now is leave it:-(

gdb - debug plugins with realplay

When I debug helix plugins with realplay, my old way, setting LD_PRELOAD, seemed do not work,mainly because realplay is an X windows application, and I can not go to the main entry point before load the shared "so". My new way to debug helix plugin is, run realplay externel on a shell:

export HELIX_LIBS=/usr/local/RealPlayer
/usr/local/RealPlayer/realplay.bin &
[1] 4175

the number 4175 will be the process id which will be used by gdb.

Then start gdb in emacs, "ESC-x gdb":

attach 4175

will attach the running process with gdb, then, I can set break points for my plugins.

When debugging, the main problem here is, the helix code is not available since I directly pull the builtin files from www.real.com, so the `next' command will complain when there's not valid code to debug. Here is a reference from RMS gdb manual:

The next command will exit any functions we can't debug (like C library functions).


Since `next' will not work if the plugs calls a function from helix, but the other command `until' still works, the only thing is, I may not like to use this command.