From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2936 invoked by alias); 21 Oct 2008 01:22:11 -0000 Received: (qmail 2927 invoked by uid 22791); 21 Oct 2008 01:22:10 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Oct 2008 01:21:35 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id m9L1LCcM032211; Mon, 20 Oct 2008 21:21:12 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m9L1LBLW006114; Mon, 20 Oct 2008 21:21:11 -0400 Received: from opsy.redhat.com (vpn-12-11.rdu.redhat.com [10.11.12.11]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m9L1LATN019058; Mon, 20 Oct 2008 21:21:11 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id DF9B250807D; Mon, 20 Oct 2008 19:20:58 -0600 (MDT) To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] add struct parse_context to all command functions References: <20081009140424.GD5372@adacore.com> <20081020161614.GB6251@adacore.com> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom Date: Tue, 21 Oct 2008 01:22:00 -0000 In-Reply-To: <20081020161614.GB6251@adacore.com> (Joel Brobecker's message of "Mon\, 20 Oct 2008 09\:16\:14 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2008-10/txt/msg00501.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> The base for the suggestion is that Tom wonders whether it might Joel> be a little excessive to push this extra argument that might Joel> actually only be used by a subset of the commands. Yeah, this is one issue. I don't understand why the parameterization is needed by command implementations. My understanding is that it is needed when resetting breakpoints (reparsing conditions or what have you). However, it seems like this could be done by simply parameterizing the parse functions and sticking a bit more state on the breakpoint. I assume I'm missing something here; I'd like to understand what. Also, why pass in this particular subset of globals? There are lots of globals in gdb, used all over. My view is that commands are by their nature singletons (unless you want to support multiple CLIs at once of course :-) and so would reasonably access global state even in a design from scratch. IOW, I think it would make sense to only bother with global-elimination for layers underneath the command functions. What do you think of that? Joel> Perhaps it's another bikeshed discussion, in which case let me know, Joel> and I'll just decide on my own. It's just that it's such a large change Joel> that I want to make sure I won't screw anyone up. It won't mess anything up for me :-) I'm interested in understanding the problem and also in everybody's thoughts on future directions for gdb's implementation. Also I'd rather you do less work if possible. FWIW I also have a vaguely similar reorganization in the wings. I removed all accesses to global variables from the value_print and val_print hierarchy, in favor of a "print options" argument. So, my interest in this sort of thing is not totally academic. I hope this isn't too bikesheddy. I'm sensitive to the possibility :-) Tom