From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81444 invoked by alias); 30 Sep 2015 08:02:15 -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 81428 invoked by uid 89); 30 Sep 2015 08:02:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f181.google.com Received: from mail-wi0-f181.google.com (HELO mail-wi0-f181.google.com) (209.85.212.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 30 Sep 2015 08:02:11 +0000 Received: by wicfx3 with SMTP id fx3so184247803wic.1 for ; Wed, 30 Sep 2015 01:02:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=jVv9RN5Si2R4oiPBjYocCfmiCOTELdxzxwg5am65zS8=; b=L3e5pbwS0noC9iOaBKFsIqefHQBE1DX7DjmBDfyngleiQc7bwmVjXZX3OrbM2aVvgc eOSJhPisbkS5GGwG/KdI0BUtygOhhKOKui3kQoitR9wCte1e1qgV14Js6E4Q3yAILkUX f7p7/W0blxAEYhJ24Fyl/oQUReBsqXPaEAqnc1Qtbma6Sjn7NLmriLcWz8PRb9taEy2Y wjF8mPKC7C33bgWvakOFh77r849Kq68FnTNDBLjYm5ABUw+QtZrFIVUBqRR4xlNTa8HO Cs0lnMpohhjtwgxLNpcTgBhj5W4qdi6n1PeTadjfP2S+SHI81JVw2y96zlYqcLo3Sqto JotQ== X-Gm-Message-State: ALoCoQnj9XnfjxIQaXrqoLv+YsKnQcNKbOvz7lZ5cgC0pELCL9X+IR2MAPAanQMCRaLRT9a3h13M X-Received: by 10.180.223.102 with SMTP id qt6mr2972492wic.11.1443600128738; Wed, 30 Sep 2015 01:02:08 -0700 (PDT) Received: from griffinp-ThinkPad-X1-Carbon-2nd (cpc14-aztw22-2-0-cust189.18-1.cable.virginm.net. [82.45.1.190]) by smtp.gmail.com with ESMTPSA id wc12sm28042956wic.18.2015.09.30.01.02.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 30 Sep 2015 01:02:07 -0700 (PDT) Date: Wed, 30 Sep 2015 08:02:00 -0000 From: Peter Griffin To: Doug Evans Cc: gdb-patches , lee.jones@linaro.org Subject: Re: RFC GDB Linux Awareness analysis Message-ID: <20150930080205.GA26183@griffinp-ThinkPad-X1-Carbon-2nd> References: <20150603142858.GA19370@griffinp-ThinkPad-X1-Carbon-2nd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2015-09/txt/msg00647.txt.bz2 Hi Doug On Thu, 04 Jun 2015, Doug Evans wrote: Thanks for your feedback, and apologies for taking so long to get back to you. No doubt you thought I'd been hit by the proverbial bus. The other activites I've been working on are now almost finished, so I should be able to start work on this GDB activity again. > On Wed, Jun 3, 2015 at 7:28 AM, Peter Griffin wrote: > > Hi GDB community, > > > > Overview > > ======== > > > > The purpose of this email is to describe a useful feature which has been developed > > by STMicroelectronics inside of GDB for debugging Linux kernels. I will cover at > > a high level some of the implementation details and what I see as the advantages > > / disadvantages of the implementation. I will also cover some other alternative > > approaches that I'm aware of. > > > > The purpose is to facilitate discussion with the GDB experts on this > > mailing list as to what the "correct" way to implement this functionality would > > be. > > > > The end goal is to have an upstream implementation of this functionality. > > > > ... > > Hi. > > > > > Questions > > - Do GDB community mind Linux specific custom commands being added to GDB code base? > > In principal, no. But the devil is in the details of course. > > gdb already has "info proc foo" to dump bits of /proc. > Plus obviously we encode various linux-specific bits > needed to debug userland apps. Ok thanks, I wasn't aware of that functionality. It's good to know about where all the current OS specific parts are in GDB. > > > My current opinion is that helper commands which can be, should be migrated from C code > > into Python, and merged into the kernel source tree (and then retired from the LKD patchset). > > I can't speak to what, if anything, "should" live in the kernel tree > (as opposed to somewhere else, but not necessarily in gdb). > Encoding application-specific knowledge in gdb is obviously not ideal, > but then again the kernel is not your average app. Certainly some python has already been accepted into the kernel, and moving parts of LKD which can be migrated into python seems like a good first step. Both from seeing how easy it is to get merged into the kernel perspective and also getting an idea of what bits maybe missing from the python API currently. > > > If you got here, thanks for reading this far! Like I said at the beginning, the purpose of > > this email is to stimulate some discussion on what you folks consider the 'correct' way to > > implement this OS awareness functionality is. > > If we can put most/all this in python, awesome. > I wouldn't be opposed to extending gdb's python API to support this > (where appropriate). Something which I believe is missing currently is the ability to add a new thread via the python interface. Is that something you would consider appropriate? By way of example, currently the kernel python scripts add a "lx-ps" which parses the task_structs, and builds a list of threads. This is the beginning of task-awareness in python, but currently the list is simply printed out. Being able to either return this thread list to GDB, or actually create thread objects inside GDB via the python interface would appear to be the next logical step. > Can we proceed by making "do it in python" the default choice, > and then address each issue as needed? Ok, sounds good to me. This was also my gut feeling when starting this analysis, but to have it confirmed by you is encouraging :). kind regards, Peter.