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

Joel Brobecker
2008-10-09T22:20:34Z

> ... 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