Re: [PATCH 3/4] Add SLAB allocator understanding.

[Petr Tesarik <ptesarik@suse.cz>]

On Tue, 2 Feb 2016 08:22:25 +0100
Jan Kiszka <jan.kiszka@siemens.com> wrote:

> On 2016-02-02 03:05, Ales Novak wrote:
> > On 2016-2-1 23:29, Doug Evans wrote:
> > 
>[...]
> >> Keeping application specific code with the application instead of gdb
> >> is definitely a worthy goal.
> >> [one can quibble over whether linux is an application of course,
> >> but that's just terminology]
> > 
> > Yeah, you're right. Yet if we're talking about the SLAB in particular -
> > considering with how many objects simultaneously has this subsystem to
> > cope, I'm afraid that adding any extra overhead (e.g. the Pythonish)
> > will be just painful.
> > 
> > It's a pitty that gdb cannot be extended dynamically, afaics.
> 
> First, don't be too sceptical before some has tried this. And then there
> are still options for optimizations, either on the language side (C
> extension to our Python modules, also in-kernel maintained) or more
> efficient interfaces for gdb's Python API.
> 
> It's definitely worth exploring this first before adding Linux kernel
> release specific things to gdb, which is going to be even more painful
> to maintain.

I agree that putting Linux-specific code into the GDB main project is a
bit unfortunate. But this indeed happens because there is no way to add
an external module to GDB. In effect, there is little choice: all code
must be either accepted by the (monolithic) GDB project, or it must be
maintained as a custom out-of-tree patch.

Now, maintaining out-of-tree code is just too much pain. This is (in my
opinion) the main reason people are so excited about Python scripting:
it's the only available stable API that can be used to enhance GDB with
things that do not belong to the core GDB. Plus, this API is incomplete
(as evidenced by Jeff's patch set), and extending it is definitely more
work than exporting existing C functions for use by modules, slowing
down further development of GDB.

Note that this limitation is more political than technical, but this
fact probably only means it's less likely to change...

Just my two cents,
Petr T