From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28327 invoked by alias); 26 Jun 2009 18:50:45 -0000 Received: (qmail 28316 invoked by uid 22791); 26 Jun 2009 18:50:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Jun 2009 18:50:38 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id DB8948015; Fri, 26 Jun 2009 11:50:36 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id D1DC4C9EBC; Fri, 26 Jun 2009 11:50:36 -0700 (PDT) Message-ID: <4A451826.3010709@vmware.com> Date: Fri, 26 Jun 2009 18:50:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: "tromey@redhat.com" CC: Paul Pluzhnikov , =?ISO-8859-1?Q?Andr=E9_P=F6?= =?ISO-8859-1?Q?nitz?= , "gdb@sourceware.org" Subject: Re: Learn function name by its address References: <8763ekb9ql.fsf@sphinx.net.ru> <8ac60eac0906250853y3f70e3b1y2bf97674b1e83d7b@mail.gmail.com> <200906260838.31341.andre.poenitz@nokia.com> <8ac60eac0906260004t4b78c1ffv47eedd2ecb4662f4@mail.gmail.com> <8ac60eac0906261035g7ad07e7fx6af9af503775b6f8@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00256.txt.bz2 Tom Tromey wrote: >>>>>> "Paul" == Paul Pluzhnikov writes: > > Paul> I think removing them would be incorrect: they do exist, MI accepts them, > Paul> they just don't work :-( > > Ugh. That seems even worse. > > Paul> Perhaps add a "NOTE: This command has not yet been implemented" > Paul> to each one? > > Or also nuke the non-working entries from the MI command table. > I can't think of a reason we'd want to have non-functional commands. > I'm sure we'd reject a new patch that added such a command. What about just commenting them out, so that the work isn't lost and someone may some day implement them? Same for the docs -- can they be left in the source and just commented out?