GSoC 2013 - RTEMS Virtualization Layer Project

Progress, Issues, Design

GDB Hell - Maybe You Get Lucky

How the heck can I debug this monster? I can show you how to survive at least a couple of minutes.

POK Partitions and GDB

How a POK partition can be debugged in general can be read in the POK Developer Documentation included in the repository.

I assume you have build POK, build RTEMS with the library provided by the POK partition, injected the RTEMS binary as part1.elf into POK and build the kernel again.

So you execute make run-gdb in rtems-guest/. Qemu will be started and pauses before it starts the guest aka POK. Now go to generated-code/cpu/ (just to shorten filenames, not necessary) and: * Invoke gdb pok.elf. * Connect to the target target remote :1234 * break pok_loader_load_partition // tab completion can be used * continue * do some single stepping until * p pok_partitions[0].base_addr contains something != 0 * add_symbol_file part1/part1.elf pok_partitions[0].base_addr and confirm now you can set breakpoints on functions in POK and RTEMS, e.g.: * b bsp_start * b virt_charWrite * b printf * b my_fflush * b pok_core_syscall

symbol-file part1/part1.elf will swap pok.elf for part1/part1.elf; now the function names from the RTEMS partition are shown. You can swap part1.elf with pok.elf when you enter the kernel.

Unfortunately, next and single don’t work, but si and ni do. The backtrace command bt will most likely just show you the current function and not the previous one. It will just be 0x00000 … . But maybe you get lucky.