From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72627 invoked by alias); 2 Feb 2016 13:22: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 72613 invoked by uid 89); 2 Feb 2016 13:22:02 -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=excited, D*siemens.com, sk:jan.kis, sk:jankis 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 13:22:01 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A07FCAD5E; Tue, 2 Feb 2016 13:21:58 +0000 (UTC) Date: Tue, 02 Feb 2016 13:22:00 -0000 From: Petr Tesarik To: Jan Kiszka Cc: Ales Novak , Doug Evans , Kieran Bingham , gdb-patches , Vlastimil Babka Subject: Re: [PATCH 3/4] Add SLAB allocator understanding. Message-ID: <20160202142157.59d9c013@hananiah.suse.cz> In-Reply-To: <56B05931.9050705@siemens.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00050.txt.bz2 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. 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