Re: [RFC/RFA] add struct parse_context to all command functions

[Joel Brobecker <brobecker@adacore.com>]

> 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