Re: [RFC/commit] parse breakpoint condition according to breakpoint location

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> So the decision was, if the language is auto, to use the language
Joel> corresponding to the breakpoint location, not the current frame.
Joel> This is what this patch implements.

Sounds reasonable.

Joel> ... But at the same time, the discussion digressed over the use of
Joel> a global. I proposed a plan for dealing with this, but it's a huge
Joel> change (adding a language parameter to the parse_* routines), and
Joel> I don't think I got feedback on how I was planning to proceed.

For reference the plan is here:

    http://www.sourceware.org/ml/gdb-patches/2003-09/msg00333.html

I would prefer never passing NULL to parse_exp_1 -- just make the
callers explicitly pass current_language.

That is just a minor detail; overall it sounds fine to me.

current_language is a problem global.  It is referenced in a lot of
places where an argument would be preferable.  E.g., even though
expressions carry their language, code in valops.c checks the global, so
you can wind up with odd behavior (at least in theory, I have not tried
to make a reproducer).  Probably, evaluate_expression should call
set_language and restore the old language in a cleanup -- though this is
a workaround and not a clean fix.

Joel> Summary of the problem: 
Joel> For the longer term, this approach is far from perfect, since it
Joel> depends on the current_language global, which may change over
Joel> time.  For instance, if the user switches from language auto to
Joel> language c between the moment he creates the breakpoint and the
Joel> moment he runs the program, the condition will get re-evaluated
Joel> using C the next time around.

Once the condition is successfully parsed, it seems to me that any
re-parsing should be done with that same language.  Maybe this is
already accomplished by the set_language calls in breakpoint.c, I'm not
sure.

Tom