Re: RFC GDB Linux Awareness analysis

On Wed, Sep 30 2015, Peter Griffin wrote:

> Hi Andreas,
>
> On Thu, 20 Aug 2015, Andreas Arnez wrote:
>
> [...]
>> So I believe posting the patches to get more feedback would be
>> worth-while.
>
> Ok, so the existing LKD code is on quite an old GDB version
> (7.6). Also the whole LKD patchset is currently quite large (15k
> LoC). So my plan was to try and reduce this as much as possible by
> removing parts of LKD that can (or already have) python
> implementations e.g. dmesg.
>
> Essentially the aim would be to try and reduce the LKD patchset as
> much as possible to the "core features" which I consider to be task
> awareness and loadable module support. At this point we could look at
> what might need adding to the GDB python API to migrate even more
> parts into python.
>
> Posting the whole patchset currently would involve porting to the
> latest GDB version and before doing that I'd like to get a better idea
> of what parts are likely to need re-writing or at least only ports the
> necessary parts.

I suggest to start with a small patch set that can be reviewed easily --
and changed, if necessary.  Such as loadable modules support, or
whatever else you deem best suited for laying the foundations for this
project.  And then see how it goes.

>[...]
>
> Does anyone have experience / thoughts on how often the existing threading
> implementations that are already inside GDB break? Presumably these are also
> tightly coupled to parsing out of tree data structures (or the libraries which
> GDB relies on to do this).
>
> I'm trying to get a feel for what the current maintenance burden is like having
> these implementations in C.

A user-space runtime usually has some sort of "debug interface" which
gives certain guarantees about reliable breakpoint targets and data
structure layouts.  Such a convention allows the GDB support to stay
pretty stable.

Ideally the Linux kernel runtime provides a similar interface.  For
instance, see the description of do_init_module() in module.c:

  /*
   * This is where the real work happens.
   *
   * Keep it uninlined to provide a reliable breakpoint target, e.g. for the gdb
   * helper command 'lx-symbols'.
   */

One thing we haven't addressed so far is testing.  Usually a new GDB
feature should come with a regression test case, such that it's less
likely to break after unrelated changes.

Maybe we can put various vmlinux- and associated crash dump binaries
into the test suite, along with a test case that loads/analyzes those.
However, such binaries can grow fairly large (many Giga- or even
Terabytes), so I'm not sure whether this is a viable option.  Maybe
remove everything from the binaries that is irrelevant to the test case?

Other ideas for testing?

--
Andreas