From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8945 invoked by alias); 19 May 2011 02:54:57 -0000 Received: (qmail 8937 invoked by uid 22791); 19 May 2011 02:54:56 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,TW_SJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 May 2011 02:54:41 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id E397A2D004; Wed, 18 May 2011 19:54:39 -0700 (PDT) Received: from pa-exht01.vmware.com (pa-exht01.vmware.com [10.113.81.167]) by mailhost4.vmware.com (Postfix) with ESMTP id D7CCAC9F76; Wed, 18 May 2011 19:54:39 -0700 (PDT) Received: from EXCH-MBX-3.vmware.com ([10.113.81.228]) by pa-exht01.vmware.com ([10.113.81.167]) with mapi; Wed, 18 May 2011 19:54:39 -0700 From: Scott Goldman To: Doug Evans CC: "gdb-patches@sourceware.org" Date: Thu, 19 May 2011 02:54:00 -0000 Subject: RE: [PATCH] Add support for `user-defined` python commands Message-ID: References: <1305761175-10188-1-git-send-email-scottjg@vmware.com>, In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 X-SW-Source: 2011-05/txt/msg00416.txt.bz2 Hi Doug.=20 > I think there's a problem to solve here (finding one's way in the > myriad of available commands), but I'm not sure this is the way to go. > [Maybe it is though.] I think you made some interesting points. From what I make of your email, t= he question you've proposed is something like "should we even have user-def= ined category at all?". I'm sure there will be a lot of opinions on this. U= I debates are tougher for me than technical ones :) I can see the discussion branching in two directions: 1) Yes, we should have a user-defined category, but we also want to either:= subdivide the user-defined commands into prefix categories, or have additi= onal custom categories. In this case, I think it follows that my patch should be applied pretty muc= h as-is (pending any necessary refactoring as requested). If legacy gdb mac= ros can enter the `user-defined` category, I don't see why new python gdb m= acros should be excluded. Further patches can add the support for additiona= l custom categories, and this patch would be the first step: allowing pytho= n macros to be classified as `user-defined` at all. 2) No, we should not have a user-defined category, and it should be replace= d by custom categories or prefix categories. In this case, my patch is pretty irrelevant.=20 At work, the macros I deal with are intended for kernel debugging on ESXi. = I was in the process of introducing our first python macro, but realized th= at all of our macros are indexed in `help user-defined` but, for whatever r= eason, the gdb python api has excluded that as one of the possible categori= es. My interim solution was to simply wrap some python gdb functions in leg= acy gdb macros (yuck!).=20 Personally, though I would prefer #1, and here's why: > Question: What if we had the ability to add new command classes? > And what if "help " could print all the commands in that command cl= ass? > Then one could add a whole suite of python commands to deal with foo > (which needn't necessarily match any existing command class), and > "help foo" would list them all. This is a nice idea, and we actually do have enough macros that categorizin= g them would probably be smart. That being said, this doesn't necessarily p= reclude having a catch-all `user-defined` category (or at least, the abilit= y to list all user-defined macros). I imagine (hypothetically) trying to fi= nd a macro and not being able to determine which obvious category I should = list.=20 > (python commands mightn't be able to be implemented as set/show/info > today, I forget, but it seems like a useful thing to at least not preclud= e). At least `info` falls under the `status` category, which a python command c= an currently declare itself under. -sjg ________________________________________ From: Doug Evans [dje@google.com] Sent: Wednesday, May 18, 2011 6:58 PM To: Scott Goldman Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Add support for `user-defined` python commands On Wed, May 18, 2011 at 4:26 PM, Scott J. Goldman wrot= e: > For codebases with a large pre-existing set of legacy gdb macros, it's > nice to be able to use `help user-defined`, to refresh your memory wrt > to existing macros. Currently, python gdb commands can't put themselves > under the `user-defined` category. This patch aims to rectify that. I think there's a problem to solve here (finding one's way in the myriad of available commands), but I'm not sure this is the way to go. [Maybe it is though.] What does "help user-defined" buy? It *does* buy a way to see a list of a particular set of available commands, but the list isn't categorized along functional lines (like managing breakpoints or examining data). What the user will get is a list of a random set of commands. For completeness sake, prefix commands provide another way of categorizing commands - one *could* put a set of new commands in a prefix command, and then "help " would list all of the commands. But it doesn't always fit what one wants to do. E.g. it wouldn't list anything added as a set/show or info command (python commands mightn't be able to be implemented as set/show/info today, I forget, but it seems like a useful thing to at least not preclude). Question: What if we had the ability to add new command classes? And what if "help " could print all the commands in that command clas= s? Then one could add a whole suite of python commands to deal with foo (which needn't necessarily match any existing command class), and "help foo" would list them all. Just a thought.