From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32561 invoked by alias); 21 Oct 2008 07:07:04 -0000 Received: (qmail 32520 invoked by uid 22791); 21 Oct 2008 07:07:02 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Oct 2008 07:06:27 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4943B2A9672; Tue, 21 Oct 2008 03:06:25 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kdgDBVtuc+ru; Tue, 21 Oct 2008 03:06:25 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id EF17E2A966C; Tue, 21 Oct 2008 03:06:24 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id D9185E7AD0; Tue, 21 Oct 2008 00:06:22 -0700 (PDT) Date: Tue, 21 Oct 2008 07:07:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] add struct parse_context to all command functions Message-ID: <20081021070622.GA4035@adacore.com> References: <20081009140424.GD5372@adacore.com> <20081020161614.GB6251@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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/msg00507.txt.bz2 > 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. Right - In terms of the parsing issue in isolation, adding a language paramenter is what is going to be needed, and what I will eventually do. In fact, this is something that I actually did. But by doing so, I realized that all I did was moving the use of the current_language global variable up in the call stack in other routines that really shouldn't be using it either. So the global purpose of the exercise has become to remove the use of the current_language global (as well as the input_radix one, which was actually recommended by Ulrich when I initially introduced this subject). The fact this should fix the problem on IRIX almost for free has almost become incidental (almost :-). On my first approach to this issue, I started from the parse routines, adding a language parameter, and slowly "propagated" this new parameter up in the call stack (that is, adding this new parameters to the callers, and using that parameter instead of using current_language). But I felt disatisfied, because the number of uses of current_language was in fact rapidly increasing. If I work from the command functions, I work with a parameter right from the start, so I won't have to increase the unwanted use of that global, even temporarily. > 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. For this thread, we need to restrict ourselves to the globals that affect the interpretation of the commands entered by the user. I chose these parameters because they have an influence on the parsing of the command arguments. There will likely be others, as hinted by Ulrich (I think he was thinking of adding the gdbarch, or something equivalent). So this might only be a start... Generally speaking, I think this fits well in the goal of avoiding the use of global variables to pass information from one routine to the next. -- Joel