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: Jan Kiszka <jan dot kiszka at siemens dot com>
- To: Ales Novak <alnovak at suse dot cz>, Doug Evans <dje at google dot com>
- Cc: 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 08:22:25 +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>
On 2016-02-02 03:05, Ales Novak wrote:
> On 2016-2-1 23:29, Doug Evans wrote:
>
>> On Mon, Feb 1, 2016 at 5:21 AM, Kieran Bingham
>> <kieranbingham@gmail.com> wrote:
>>> This is interesting work!
>>>
>>> I had been discussing how we might achieve managing this with Jan @
>>> FOSDEM yesterday.
>>>
>>> I believe a python implementation of this could be possible, and then
>>> this code can live in the Kernel, and be split across architecture
>>> specific layers where necessary to implement handling userspace
>>> application boundaries from the Kernel Awareness.
>>
>> 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.
Jan
--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux