From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55875 invoked by alias); 2 Feb 2016 10:04:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 55859 invoked by uid 89); 2 Feb 2016 10:04:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=checkout, contrib, peopleredhatcom, UD:people.redhat.com X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 02 Feb 2016 10:04:01 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2FE3FAC86; Tue, 2 Feb 2016 10:03:58 +0000 (UTC) Subject: Re: [PATCH 3/4] Add SLAB allocator understanding. To: Kieran Bingham , Ales Novak , gdb-patches@sourceware.org References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <1454276692-7119-4-git-send-email-alnovak@suse.cz> <56AF5BC8.4010509@gmail.com> Cc: Jan Kiszka From: Vlastimil Babka Message-ID: <56B07F0D.308@suse.cz> Date: Tue, 02 Feb 2016 10:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56AF5BC8.4010509@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00044.txt.bz2 On 02/01/2016 02:21 PM, Kieran Bingham 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. Hi, I understand that the idea of python scripts living in the kernel tree looks desirable, but I see several practical drawbacks. My main goal with this is to have a better replacement for the crash [1] tool for kernel crash dump analysis. The tool supports dumps from a range of kernel versions, and so should the replacement. We regularly deal with crash dumps from 3.0-based and newer kernels, so backporting some kernel-version-specific python scripts to those kernel versions (or even older) is infeasible. Then we would have to assume that any kernel patch author changing a subsystem doesn't forget to update the in-kernel scripts, otherwise they easily get out of sync in the git history. Lastly, it's bit more comfortable if the only input you need is the dump, vmlinux and vmlinux.debug, without having to checkout scripts from git. So I believe it's better if the tool could understand and work with a range of kernel versions by itself, like crash. The split between functionality in C and python is a separate question. I understand you wouldn't want to add all the required knowledge into gdb proper, so what other options are there? Some kind contrib/python/kernel directory for the python scripts? (but not version specific?). How can we similarly separate the required C code, if it turns out that doing *everything* in python, wrapping only the lowest-level gdb concepts would be too slow? Thanks, Vlastimil [1] https://people.redhat.com/anderson/