GDB Python

This project add support for RTEMS in GDB using Python.

Recent versions of GDB ship with Python embedded as a scripting language. This was added so GDB could be extended using a fully featured scripting language. The embedding of Python into GDB currently provides Pretty Printing hooks. Pretty printing allows GDB to be extended to provide human readable output for complex structures that do not print clearly using the actual type structure. The first use was to hide the C++ STD details.

Python in GDB allow the RTEMS project to extend GDB so RTEMS's various data types can be presented in a human readable manner or made accessible to GDB.


The RTEMS GDB Python code can be downloaded from

Contact Chris Johns? or Dhananjay? if you are interested in helping with this work.


This project is on going. There are large number of types and structures in RTEMS and having them all accessible from GDB is a large undertaking. The initial phase is to support the basic types needed by RTEMS users to debug RTEMS applications. They are:

# Objects # Objects_Control # Objects_Name

  • Classic

# Attributes # Tasks # Semaphores # Message Queues # Paritions # Regions # Periods # Extensions # Barriers


# Threads # Keys # Message queue Fds # Message Queues # Mutexes # Semaphores # Condition Variables # Timers # Barriers # Semaphores # Read/Write? Locks

List of pretty printers added # rtems_id # Objects_Id # Objects_Name # Objects_Control # States_Control # rtems_attribute # Semaphore_Control

A RTEMS command call 'rtems' has been added that have sub-commands added. The sub-commands are:

# object

RTEMS Object Command

The command takes a single parameter an object id and prints the object details it references. The object id can be a number or a variable that contains a valid id. For example:

Breakpoint 6, rtems_semaphore_obtain (id= = {...}, option_set=0, timeout=0) at \


(gdb) rtems object id API:classic Class:semaphores Node:1 Index:18 Id:1A010012

Name: DDEV Attr: 0x00000010,local,fifo,bin-sema,no-inherit-pri,no-pri-ceiling Lock: unlocked

Nesting: 0 Blocked: 0

Holder: unlocked

Queue: len = 0, state = waiting-for-mutex

You could look at the object with <tt>rtems object 0x1a010012</tt> or <tt>rtems object 436273170</tt>. For a task you can do:

(gdb) rtems object _Thread_Executing-> API:classic Class:tasks Node:1 Index:7 Id:0A010007

Name: fsts

State: ready

Current: 160

Real: 160

Suspends: 65536 Post Ext: false

Preempt: true

T Budget: 48


This project is currently in development. Please contribute.


Better prompt

The python-interactive command was not working for me, So I used the following method to obtain an interpreter(It is better than the stock if you are debugging the python code) -

# Interactive Ipython from IPython.zmq.ipkernel import IPKernelApp app = IPKernelApp.instance() app.initialize([]) app.start()

Save this as and do a source from gdb. Then you can connect to the interpreter using

ipython console --existing kernel

Better Error messages

Make GDB print the whole python exception

set python print-stack

Handle Errors And Exit

raise gdb.GdbError?("Reason")


Documentation on how to use GDB Python was requested, so add a README to the general TODO.


  • GDB Python is documented in the user manual of GDB under the heading Extending GDB.


The project is suitable as a GSoC project. The project requires a student that:

# Has completed the hello world demo required by all RTEMS GSoC strudent # Some knowledge of Python and using classes in Python # Ability to code in C. We may require changes to GDB. I suppose this may require paperwork with the FSF to assign copyright. # The ability to learn, understand and use some of the Embedding Python details.

The major focus of the GSoC work is to look at threading and to teach GDB about RTEMS threads. The may require GDB having thread information added to the 'gdb' package exported from GDB to Python as well as hooks for calls when a break point is hit so the RTEMS Python code can read the thread information into GDB.

The concept of adding thread support via Python is based on the way GDB currently asks a remote server for thread information if the remote server indicates it supports threads. The idea is to enhance GDB to call a Python hooked function to fetch the thread specific data and a to provide a mean of getting the thread information back into GDB.

Update: This project has been accepted into GSoC 2013. Link to the proposal.

Last modified on 08/16/13 at 22:12:28 Last modified on 08/16/13 22:12:28