From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81444 invoked by alias); 1 Feb 2016 22:30:35 -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 81430 invoked by uid 89); 1 Feb 2016 22:30:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=cooperate, worthy, our X-HELO: mail-vk0-f41.google.com Received: from mail-vk0-f41.google.com (HELO mail-vk0-f41.google.com) (209.85.213.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 01 Feb 2016 22:30:32 +0000 Received: by mail-vk0-f41.google.com with SMTP id e185so85802563vkb.1 for ; Mon, 01 Feb 2016 14:30:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8vlKVWlCp+BdL1jxFc3WbLQuLzLpYz7yQgUl28FggWM=; b=b1LfCb3ZAMz//jv92uECRFTIRJF12GEuoUmbX/QuG+viXbejFBboZc0WibSEbAoyjj 38UVVp4+5UYZJcWnBjH+wa0J0MeMgbrXG4gzjjtGbHQ0kQk/xWDGbaf1AOkWDK3OQwAd I1KDcWWpLtzEn4+NjXS7IUU3cPNs1SYcPFI1hDCD+tjbtzblvnHNQGhT0ZvKcXlfzeDI esQfGw9Zu8tLjoTt0xa8lHDONZe7N8nXTJWZ5GeD0cugpFszHzjduQergfq0COErZW1H CG4pZEGZMHSsvbA6+cFbXrPa5+0AmJEf1hLOrDaFdoN6Qfw7muzhqRHxKHpGAD1elXim Ng0g== X-Gm-Message-State: AG10YOTmI0uuuJnnDek30eQBRIzfZYEsCrKCENLrImXx2dq/r1VjQZJrrLXa8OcoowVtV+hVTpMvuJSHBZjwrFSW X-Received: by 10.31.21.3 with SMTP id 3mr17741232vkv.132.1454365830454; Mon, 01 Feb 2016 14:30:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.148.216 with HTTP; Mon, 1 Feb 2016 14:29:50 -0800 (PST) In-Reply-To: <56AF5BC8.4010509@gmail.com> References: <1454276692-7119-1-git-send-email-alnovak@suse.cz> <1454276692-7119-4-git-send-email-alnovak@suse.cz> <56AF5BC8.4010509@gmail.com> From: Doug Evans Date: Mon, 01 Feb 2016 22:30:00 -0000 Message-ID: Subject: Re: [PATCH 3/4] Add SLAB allocator understanding. To: Kieran Bingham Cc: Ales Novak , gdb-patches , Vlastimil Babka , Jan Kiszka Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00030.txt.bz2 On Mon, Feb 1, 2016 at 5:21 AM, 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. 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] > 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. I hope someone will take this on.