Hi Everyone,
While developing applications for Genode I sometimes run into bugs and issues where a debugger would be of great help to figure out what I'm doing wrong. Reading Genode Foundations section 4.7.2 the GDB monitor approach seems to be exactly what I'm looking for.
So when I try the gdb_monitor build-process as described at http://genode.org/documentation/developer-resources/gdb I get the following error message:
$ make app/gdb_monitor checking library dependencies... Library-description file gdbserver_platform.mk is missing
Digging a little deeper it seems I do have this file, however it's not available for my platform (Ubuntu Linux 14.04 64bit). Searching the web for this issue I find a post from May 2014 (http://sourceforge.net/p/genode/mailman/message/32372505/) which seems to be the issue I'm running into. The proposed solution is to use 32bit Linux.
What I could do is setup a VM with 32bit Linux and do my debugging here. However I prefer doing my debugging at my workstation natively without switching to a VM whenever I run into an issue.
So I wondered whether there is any way to do my gdb debugging on a 64bit workstation. Did I miss a source which explains how to do things on a 64bit system? Is a gdb_monitor for 64bit Linux on it's way? Would there be any way to use the gdb-monitor for 32bit Linux on my 64bit system? Is there another system in place for 64bit debugging?
Any help would be appreciated.
Kind regards, Menno
Hi Menno,
on the 'linux_x86' Genode platform, we usually use the GDB of the host Linux system for debugging. There are some limitations on the GDB features that can be used, for example, breakpoints in shared libraries might not work. But features like showing a backtrace usually work.
For example, if a segmentation fault occurs reproducibly in a Genode program, I would do the following:
1) let the program pause at a time before the crash occurs
On the 'linux_x86' platform, a function 'wait_for_continue()' exists, which waits until the user presses the Return key on the log console. This function could be called, for example, at the beginning of 'main()'. The function must be declared in the file where it is being used as:
extern "C" void wait_for_continue();
2) execute the run script of the test scenario
The thread to be debugged should now be waiting in 'wait_for_continue()'.
3) find out the thread ID of the waiting thread
The command
$ ps -eLf | grep Genode
shows a list of running Genode threads. The thread ID is the last of the three IDs shown in each row.
4) start GDB and attach it to the thread
In the 'build/linux_x86/bin' directory, run
$ gdb <name of program ELF image> -p <thread id>
5) let the program continue until the crash occurs
- in GDB, enter 'cont' - on the Genode log console, press Return
Now, if the segmentation fault occurs, GDB stops and the backtrace can be shown.
Hope this helps, Christian
Hi Christian,
Thank you for your reply. Yes, this certainly makes life much easier!
Menno
On 11-12-15 13:24, Christian Prochaska wrote:
Hi Menno,
on the 'linux_x86' Genode platform, we usually use the GDB of the host Linux system for debugging. There are some limitations on the GDB features that can be used, for example, breakpoints in shared libraries might not work. But features like showing a backtrace usually work.
For example, if a segmentation fault occurs reproducibly in a Genode program, I would do the following:
- let the program pause at a time before the crash occurs
On the 'linux_x86' platform, a function 'wait_for_continue()' exists, which waits until the user presses the Return key on the log console. This function could be called, for example, at the beginning of 'main()'. The function must be declared in the file where it is being used as:
extern "C" void wait_for_continue();
- execute the run script of the test scenario
The thread to be debugged should now be waiting in 'wait_for_continue()'.
- find out the thread ID of the waiting thread
The command
$ ps -eLf | grep Genode
shows a list of running Genode threads. The thread ID is the last of the three IDs shown in each row.
- start GDB and attach it to the thread
In the 'build/linux_x86/bin' directory, run
$ gdb <name of program ELF image> -p <thread id>
- let the program continue until the crash occurs
- in GDB, enter 'cont'
- on the Genode log console, press Return
Now, if the segmentation fault occurs, GDB stops and the backtrace can be shown.
Hope this helps, Christian
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello,
I have a tiny hint in addition to Christian's perfect guide, which can be added in your build directory to the file etc/tools.conf:
CC_OLEVEL = -O0 -fno-omit-frame-pointer -gdwarf-2
The first two options instruct the compiler to optimize less and make backtraces better reproducible. The last option is required for older versions of GDB (for me it's 7.4 on Ubuntu 12.04), which do not support more recent versions of the DWARF debugging information.
Regards