GDB Linux Awareness revisited

Andreas Arnez
Fri Jan 29 19:09:00 GMT 2016

On Mon, Jan 18 2016, Kieran Bingham wrote:

> Hi Yao, et al,
> I am currently working through the GDB Linux Awareness project, started
> by Peter Griffin and originally discussed in the gdb{,-patches}
> mailinglist in June 2015
>  []
> The main points that I took from that discussion were that it was a
> valuable contribution to make, and that the main focus should be on
> writing the support using the Python Extensions, so my hope is to try to
> extend the python interfaces where possible to maximise the kernel
> specific code living in the kernel.

I am sure everybody agrees that "Linux awareness" would be a valuable
contribution to GDB.  And I doubt that you will encounter much
opposition against adding kernel specific code to GDB, unless it is
actually kernel *version* specific.  IMO, then it depends on the
expected amount of change over time.

Just in case you haven't seen, I presented this slide deck at the last
GNU Tools Cauldron:

These slides were mainly intended to give food for thought and get the
discussion going.  There were some follow-ups on the GDB mailing list,

  * About the gdb-kdump project:

  * About Linux Awareness and LKD:


>  * Module Symbol loading and break pointing support
>    - Fairly well supported already by the existing linux.git/scripts/gdb
> work

This only works if the debug target uses *virtual* rather than physical
kernel addresses, right?  Is this typical for the scenarios you want to


> Support for the frame-unwinders are already exposed via the Python
> API's, however access to the gdb thread_list is not yet available, and
> this is where I will be hacking next.
> Briefly chatting on IRC, Pedro mentioned that exposing this support
> could help for other runtimes such as Go subroutines, so my hope is that
> this work will be re-usable in other places too.

Right, such a Python interface may be usable for Goroutines.  Here's the
Golang community's current approach to this:

Due to the Python interface's limitations, that script defines a command
"info goroutines" instead of supporting "info threads".  It also offers
a command prefix "goroutine <id>", rather than allowing the user to
switch contexts with "thread <id>".

Also note that gccgo has a different runtime and is not supported by
the script above.


More information about the Gdb mailing list