This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/4] Add SLAB allocator understanding.
- From: Petr Tesarik <ptesarik at suse dot cz>
- To: Jan Kiszka <jan dot kiszka at siemens dot com>
- Cc: Ales Novak <alnovak at suse dot cz>, Doug Evans <dje at google dot com>, Kieran Bingham <kieranbingham at gmail dot com>, gdb-patches <gdb-patches at sourceware dot org>, Vlastimil Babka <vbabka at suse dot cz>
- Date: Tue, 2 Feb 2016 14:21:57 +0100
- Subject: Re: [PATCH 3/4] Add SLAB allocator understanding.
- Authentication-results: sourceware.org; auth=none
- References: <1454276692-7119-1-git-send-email-alnovak at suse dot cz> <1454276692-7119-4-git-send-email-alnovak at suse dot cz> <56AF5BC8 dot 4010509 at gmail dot com> <CADPb22TmSdnwd9MCo=jf-dLoqQE-O2VROxzRd7p+xee=-_CG0w at mail dot gmail dot com> <alpine dot LSU dot 2 dot 03 dot 1602020243520 dot 5343 at suse dot cz> <56B05931 dot 9050705 at siemens dot com>
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