Re: GDB Linux Awareness revisited

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
>  [https://sourceware.org/ml/gdb-patches/2015-06/msg00040.html]
>
> 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:

  https://gcc.gnu.org/wiki/cauldron2015?action=AttachFile&do=get&target=Andreas+Arnez_+Debugging+Linux+kernel+dumps+with+GDB.pdf

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,
e.g.:

  * About the gdb-kdump project:
    https://sourceware.org/ml/gdb/2015-09/threads.html#00014

  * About Linux Awareness and LKD:
    https://sourceware.org/ml/gdb/2015-10/threads.html#00000

[...]

>  * 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?

[...]

> 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:

  https://golang.org/src/runtime/runtime-gdb.py

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.

--
Andreas