using gdb on a PocketBook device

[rkomar]

I figured out how to partially debug an application on a PocketBook device, so I thought I'd outline the steps here in case others find it useful.

Firstly, I tried running gdb on the device within a utelnetd session, but was unable to pass commands to it. gdb uses ncurses to handle input, and I suspect that that just doesn't work without a proper terminal. So, I went with using gdbserver on the device, and then doing the debugging on another machine over WiFi. The following are the steps required to get that working:

1) You need a computer that can run and debug ARM binaries. I used LoneTech's old qemu disk image and ran it on my desktop. The link is available within an old message here: https://www.mobileread.com/forums/sho...18&postcount=1. Alternatively, you can install a fresh Debian Lenny armel system within qemu, and then install the PocketBook arm-none-linux-gnueabi libraries within it.

2) Install gdb and libreadline5 within the ARM system. I just grabbed the packages from the Debian Lenny armel website and installed them with dpkg.

3) Copy /usr/bin/gdbserver from the ARM system to the PocketBook device. If you have networking enabled within the ARM system, you can scp the file to your desktop, and then copy it to the PocketBook device from there.

In my case, my ARM system is setup to only talk to the host via the bridging network. The default setup for that is that the host is at address 10.0.2.2. Within my LAN, my host has the address 192.168.1.20, and the PocketBook device is at 192.168.1.160.

As an example, I'm going to describe debugging the pbterm program. The pbterm.app and pbterm.cfg files need to be copied to the ereader in /mnt/ext1/applications/. The source code and debuggable version of pbterm should be copied to the ARM system, as well.

4) Get a shell on the ereader (I use utelnetd) and run gdbserver on it, specifying the IP address of the machine that will be allowed to access it, as well as the port number. Because my ARM system is running under bridged networking, I specify the IP address of my host:

> cd /mnt/ext1/applications/
> /mnt/ext1/bin/gdbserver 192.168.1.20:1234 ./pbterm.app

5) Within the ARM system, you need to run the pbterm.app executable within gdb. You'll probably have to add the location of the PocketBook libraries to your LD_LIBRARY_PATH environmental variable if they aren't in one of the default system locations. Within LoneTech's image, they are at /root/pbroot/ebrmain/lib/. The pbterm sources and executable are within the pbterm-1.2.1-debug.tar.gz file:

> tar zxf pbterm-1.2.1-debug.tar.gz
> cd pbterm-1.2.1-debug
> export LD_LIBRARY_PATH=/root/pbroot/ebrmain/lib

6) Check that the application can see the pocketbook libraries:

> ldd ./pbterm.app

should show no missing dynamic libraries in the list.

7) Within gdb, you need to set the location of the pbterm source files, and also the location of the remote gdbserver. For pbterm, the source files are in the src/ directory:

> gdb pbterm.app
gdb> dir src
gdb> target remote 192.168.1.160:1234
gdb> continue

The application will then run on the ereader, and the results can be seen on the ARM system. You can set breakpoints before the continue statement. For example,

gdb> break Term::get_shell_output


I hope this information helps some debug their applications.

[rkomar]

I just discovered today that gdb runs fine within the pbterm application. So, if you can use pbterm as your commandline interface, then you don't need to do remote debugging via gdb.

You need to install gdb, libncurses.so.5 and libreadline.so.5 from the debian lenny armel distribution. Install gdb to /mnt/ext1/system/bin. Install the two libraries to /mnt/ext1/system/lib. Then within pbterm on the device:

export LD_LIBRARY_PATH=/mnt/ext1/system/lib
export PATH=/mnt/ext1/system/bin:$PATH
gdb <program-path>

You can use the multi-task menu on the device to switch between pbterm and the application if necessary.

I've provided the gdb binary and the two libraries that I copied from the debian lenny armel distribution as an attachment. Sources for those are available in the debian archives.

[rkomar]

One last tidbit: if you want to use gdb with the utelnetd or sshd terminals to just get a simple stack trace at a crash, you can redirect the commands to gdb rather than trying to type them at the prompt (which doesn't work). For example, using a here document (i.e. "<<"):

gdb <program-name> <<EOD
run [arguments-to-program]
where
quit
EOD

will run the program in the debugger, and then run the "where" command and "quit" at the crash point.

You can also copy the gdb commands into a file, say gdb.txt, and then redirect those to gdb through standard input:

gdb <program-name> <gdb.txt

The latter is handy if you are re-running the program many times while testing.