Share Your Debugging Scripts | Interrupt

One of my favorite ways to debug is to let GDB and a set of previously written Python scripts do all the work for me. These scripts could parse the heap and data structures, investigate fault registers, and paint an accurate picture of a system at the time of a crash.

This is a companion discussion topic for the original entry at
1 Like

Thanks for the interesting article
could you please tell me the difference between arm-none-eabi-gdb and arm-none-eabi-gdb-py? I think the latter has to do with python but that’s all I know.

In the standard ARM distribution of the compiler, arm-none-eabi-gdb-py is compiled with Python support and can run Python scripts. arm-none-eabi-gdb cannot.

Here’s a GDB script for dynamically loading debug symbols for TockOS userspace applications. It required a very simple modification to the kernel (not shown). I’m not proud, but it worked at the time:

# The following code breaks on hook we have added to `` and
# observes process loading. It reads the process's name & `.text`
# section address and uses that information to:
# 1. Infer what `.elf` file we need to load to get debug symbols for the process
# 2. Load the symbols with correct `.text` offsets so GDB knows the
#    actual location of functions and data
# NOTE: This code does not load anything onto the chip. The processes
# are already on flash and Tock takes care of starting them.
break load_process_hook
  set $APP_NAME = name.data_ptr
  # The `+ 40` below is to compensate for the fact that the Tock
  # kernel does not return the actual location of process `.text`
  # section, but the beginning of it's `APP_MEMORY` region.  To fix
  # this properly, we will need to add a method to Tock's `Processes`
  # type to return the correct address.
  set $APP_TEXT = text_addr + 40
  eval "add-symbol-file apps/%s/build/cortex-m4/cortex-m4.elf %d", $APP_NAME, $APP_TEXT
  tbreak main
  tbreak __assert_func
    up 1