Re: GDB Linux Awareness revisited

[Kieran Bingham <kieran.bingham@linaro.org>]

On 29/01/16 19:09, Andreas Arnez wrote:
> 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.
The code from ST, which has been used since Linux 2.6.32 has already
been littered with various conditional paths for versions. This is
partly why I am trying to get as much of the kernel specific code to
function correctly in the python layer, so that it can live side by side
in the correct versions.

Backporting to earlier versions can become much cleaner, with simply
making the adjustments on that branch, rather than a wave of conditionals.

By ensuring that kernel specific code lives in the kernel (therefore as
Python) GDB will not be tied to supporting only a select set of kernel
versions.

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

Yes, for the most part.

STLinuxLKD does in fact implement various memory functions including
virtual/physical address translations.
It provided the ability to control the MMU and adjust accordingly. My
discussions with Jan at the weekend suggested that this may not be a
desired route forward so it will need some more consideration.

And of course these were ARMv7 specific of course, and we would have to
look at how things get layered to consider performing mappings in the
future.

> [...]
>
>> 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

Thankyou, I had not seen this.

However, it does look very close of course to how they tasks are
currently listed in linux/scripts/gdb/ so perhaps we could work towards
a common way to implement this.

Have you seen my RFC regarding the gdb.Target layer object
representation? A python class here could iterate the tasks, and parse
the information for the info threads through hooks on the
.to_update_thread_list target operation and it's pals ...
> 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>".
Ok - so perhaps we could fix this with GoSubroutineAwareness(gdb.Target)

> Also note that gccgo has a different runtime and is not supported by
> the script above.
And perhaps a companion GccGoSubroutineAwareness(gdb.Target) could be
written to support this. :)
> --
> Andreas

Thankyou for your input, I see you have been following these topics for
a while, and you appear to be providing some of the glue between the
separate parties involved!

Regards

Kieran