Re: [RFC/RFA] Introduce new struct parse_context

[Joel Brobecker <brobecker at adacore dot com>]

> > How about the following compromise: I describe again roughly what the
> > problem is and how I am going to address it. Then you can decide what
> > to add to gdbint, and where.
> 
> Okay, let's try that.

Great! Here is the problem - It shows up more often on mips-irix.
Using an Ada program named foo:

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

procedure "Foo" is the name of the main subprogram, the equivalent
of "main" in C. The difference with C is that Ada entity names follow
an encoding - for instance, in our case, the Ada mode in GDB understood
that "foo" was the main subprogram, and that its real (aka "linkage")
name is actually "_ada_foo".

As soon as the program was started, the loader mapped the shared libraries,
and that caused all breakpoints to be re-evaluated. This is done using
the following sequence:

    breakpoint_re_set_one
       -> Set current_language global to breakpoint language
       -> Re-evaluation of the breakpoint location
       -> Reset current_language to intial value

This works well most of the time, but not always. What happens
sometimes is that the current_language gets unexpectedly switched
up from under our feet as a side-effect of calling select_frame().

I have faced this type of problem in the past before, and we discussed
the idea of having the language be a parameter of the parsing routine,
but an easy workaround was also available and so the work-around was
installed and the idea postponed.

Unfortunately in this case, I turned the problem in everyway possible,
and I couldn't find an easy work-around. I actually think that this is
a fortunate thing, as it forces us to move forward in fixing the
weakness in that part of the GDB technology. Later on, Ulrich also
mentioned that the language was not the only parameter that influences
the parsing, there is also the input_radix.

The solution is to get rid of using the global current_language to
parse any expression, but to pass it as a parameter of the parsing
routine. Same for the input_radix. Because there will be more than
one such parameters to pass, we decided to create a new structure
that holds them all, and pass that structure to the parse routine.

This is a simple change on paper, but will require large updates
in the sources, because most callers of the various routines have
also been assuming that the current_language should be used. So
these routines should also be updated to take an extra parameter
as the parse_context. This in turn means that the callers' callers
also need to be updated, etc etc etc, until we reach the command
routine.

I hope this clarifies the problem we're trying to solve, and
the designed escape. I am planning to start working on the code
aspect this week, while things are quiet at the office, and will
work on documentation with you in parallel.

-- 
Joel