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: Kieran Bingham <kieran dot bingham at linaro dot org>
- To: Doug Evans <dje at google dot com>
- Cc: Ales Novak <alnovak at suse dot cz>, gdb-patches <gdb-patches at sourceware dot org>, Vlastimil Babka <vbabka at suse dot cz>, Jan Kiszka <jan dot kiszka at siemens dot com>, Lee Jones <lee dot jones at linaro dot org>, Peter Griffin <peter dot griffin at linaro dot org>
- Date: Tue, 2 Feb 2016 08:11:33 +0000
- 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>
On 01/02/16 22: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]
It's just a big fancy application which supports modules, and can talk
to hardware. :D </me ducks to avoid the flying bricks>
>
>> I believe that if properly abstracted (which I think it looks like this
>> already will be), with kdump as a target layer, we can implement the
>> Kernel awareness layers above, so that they can be common to all of our
>> use case scenarios.
>>
>> I have recently proposed creating a gdb.Target object, so that we can
>> layer the kernel specific code on top as a higher stratum layer. This
>> code can then live in the Kernel, and be version specific there, and
>> would then cooperate with the layers below, be that a live target over
>> JTAG, or a virtualised qemu/kvm, or a core dump file:
>
> Providing gdb.Target is also a worthy goal.
Perfect, I'm glad to hear this
> I hope someone will take this on.
That's my current Work In Progress.!
--
Kieran