From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77561 invoked by alias); 2 Feb 2016 14:42:13 -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 77541 invoked by uid 89); 2 Feb 2016 14:42:11 -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=conducive, investment, automate, sial 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 14:42:04 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 831DEAAB4; Tue, 2 Feb 2016 14:42:01 +0000 (UTC) Subject: Re: [PATCH 3/4] Add SLAB allocator understanding. To: Petr Tesarik , Jan Kiszka References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <1454276692-7119-4-git-send-email-alnovak@suse.cz> <56AF5BC8.4010509@gmail.com> <56B05931.9050705@siemens.com> <20160202142157.59d9c013@hananiah.suse.cz> Cc: Ales Novak , Doug Evans , Kieran Bingham , gdb-patches , Vlastimil Babka From: Jeff Mahoney X-Enigmail-Draft-Status: N1110 Message-ID: <56B0C035.2020902@suse.com> Date: Tue, 02 Feb 2016 14:42:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160202142157.59d9c013@hananiah.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00059.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/2/16 8:21 AM, Petr Tesarik wrote: > On Tue, 2 Feb 2016 08:22:25 +0100 Jan Kiszka > 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. I only partially agree here. Using Python to extend GDB to support e.g. libkdumpfile would be a workaround. I looked into it briefly and decided against it. Extending the Python API has been an investment, though. Nearly everything I'm doing in the GDB code is generic. I really do want to have most of the functionality we have now with crash implemented as Python modules. Extensions in crash need to be compiled in, written in sial, or use the grafted-on python plugin for it. All these options are terrible and not at all conducive to collaborative, iterative improvement. As we build up more infrastructure, it becomes a lot easier for people to write quick commands to automate a lot of the work we end up forced to do to get crash to do what we need. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWsMA1AAoJEB57S2MheeWyKQYP/R2kZ2vTYWtom789eS/45FaY mIWD8EsBlShfF+2ja8EdOHs6TYrkMEGTzjQIhoCJXttegwKY2H8/GXHfODuelaa6 pX5pPWNkV4v1G933NfOsfxJOEecdMAwM8MI+3HFl0I5cjw+/2xXhoEUg6+ZburlT dU1lljlQwD3+wK5Q4L/w1jBebsTUKDAvJAuoHwVNFygKBkp0h6jqf310J7PfpzR/ S/gcoSsORUrla6pdPEaFAG3lFh6mqlNlaLPKF1GghP2/RdOY0f/Ud81l36Zlu5QI D8YYtouR3qRzAf8XEV5qFMPUQDRL2c5U6JeLkJ06HxtgK44xV+l2AZar6YNezsaM zLWyYN42x7W4DDVTrWVqgx9hkrhWYdLxavY48+n8DZncqSraM6F3YorghTfUSGnF LutLEaBFHHURQfqFDAo8tEN8oT56YAKqRO5NOM2I9vZUdyizVaoCXov5fxiJHBpr urq2vl8GCXQbg5QLUbR+Fj5E3XJZbe06OT7Oy48hECFRhwEotKqggcKgmJx2/v2H dk1lLXaKI170OajZz91FVMLrOGARrWe1ZRMUa15slhIyeRUuuru7qH9jbEpBFV+b LSpAax14+/pWKMFWZrkZglxAtj6QDfFzRz+zVCDzYHLKpO+2Jct51Oas69jL7bnl xNsosBME7X/IsKjmIfmn =g4Fu -----END PGP SIGNATURE-----