Daniel Jacobowitz wrote:
> On Mon, Mar 05, 2007 at 03:37:15AM +0000, Pedro Alves wrote:
>   
>> I've looked at several ways to fix it, and all but this one turned out more
>> invasive than I hoped for, because current_language is used in a several 
>> places
>> (in symtab.c).  Instead, I simply wrapped linespec.c:find_method with a
>> set_language (lang of A), guarded with a cleanup.
>>     
>
> How much invasive?  I don't like the global "current language"; like
> the global "selected frame", it's prone to this sort of problem when
> we'd really rather be looking at a different language.
As my first approach I had added a new parameter to lookup_symbol, and
changed all the calls throughout to pass the language that seemed to
make sense or current_language otherwise.  I ended up touching many
files I wouldn't be able to test, like fortran, scheme, java and ada
support.  It was more invasive than I could afford :) (,and probably wrong).

As an intermediate step, I came up with this version.  It adds a new
lookup_symbol_in_language, and tweaks a few worker functions to accept
the language by parameter, instead of relying on the current language.
lookup_symbol is then a simple wrapper that passes the current_language
to the new lookup_symbol_in_language.  I needed to tweak ada-lang.c,
because the lookup_symbol_in_language name was already taken  there.  The
approach implemented there was similar to my previous patch, that is, it
temporarily switched the current language [1].  As I don't have an ada
compiler (and I can't fit any on my machine), I can't be be sure I caught
all the hard coded current_language uses, so I've just make the ada
function static and added a FIXME.  Maybe someone will be able to try
with the new version in symtab.c.

What do you think of this approach?

Tested on i686-pc-cygwin, no regressions.

Cheers,
Pedro Alves

[1] http://sourceware.org/ml/gdb-patches/2004-06/msg00152.html