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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> 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