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

[Joel Brobecker <brobecker at adacore dot com>]

> ... but I didn't see an explanation of the problem.  Would you mind
> repeating it?

Sure, http://www.sourceware.org/ml/gdb-patches/2007-10/msg00181.html:
> There is a project that I'm itching to start is to rework a bit our
> expression evaluation interfaces to use an explicit language rather
> than relying on the current_language global. The reason for this is
> that it will make it much clearer which language is to be used and
> will prevent some oopsies that can appear during situations like:
> 
>     breakpoint_re_set_one
>        -> set language to breakpoint language
>        -> re-evaluation breakpoint location
>        -> reset language to intial value
> 
> I have seen some cases, especially during the inferior startup
> phase, where we inadvertandly switch the language to an irrelevant
> value because as a side-effect of calling "select_frame ()". As
> a result, we end up evaluating the breakpoint location using
> the wrong language!
> 
> On mips-irix, we end up getting errors like this:
> 
>     % gdb foo
>     (gdb) b foo
>     Breakpoint 1 at 0x1000278c: file foo.adb, line 4.
>     (gdb) run
>     Starting program: /kern.a/brobecke/head/ex/foo
>     Error in re-setting breakpoint 1:
>     Function "foo" not defined.
> 
>     Program exited normally.
> 
> I think it's going to be a lot cleaner to pass a specific language
> to the parser/evaluator rather having it use the current language.
> And it's going to help us fix that problem above. Right now, I'm
> not sure I can find a solution as we have done a few times in the
> past already.

> struct cmd_list_element already has some support for multiple styles
> of callback.  It seems to me that you could limit your change to a
> subset of all the commands by adding a new field to the 'function'
> union.  (That would mean more add_* functions, though.)

Do you mean adding new "add_..." commands, and transitionning the old
ones to the new ones gradually? That should work indeed - the trickiness
is related to the fact that some of the command functions are used for
more than one commands through "add_cmd" and "add_prefix_cmd". For
instance in breakpoint.c:

  add_prefix_cmd ("enable", class_breakpoint, enable_command, ...);
  if (xdb_commands)
    add_com ("ab", class_breakpoint, enable_command, ...);

If I provide replacement versions for all the add_... commands right
from the start, it should allow us to transition gradually. I could
propose the following:

  . First patch: Rename all the add_... functions into add_..._nopc
    (for "NO Parse Context"). That's a mega-patch, but should be
    automatable.

  . Second patch: Add the add_... functions back, with the new
    interface.

  . Followup patches: Transition each file one after the other.

  . Final patch: When the old functions are no longer used, we remove
    them.

I'm Ok with this either the initial approach where everything is
transitionned all at once.  I don't really prefer the gradual transition
because it doesn't avoid the mega patch issue, makes the transition
last over a longer duration, and is in fact a little more work for
me. But I don't mind using the gradual approach is people prefer that.

-- 
Joel