[RFC] lookup problem in blockframe.c:inside_main_func()

[Daniel Jacobowitz]

[First of all, what path takes you through lookup_symbol to that
prompt?  That shouldn't ever happen, unless it's being generated in
Ada-specific code...]

On Mon, Oct 06, 2003 at 04:37:29PM -0700, Joel Brobecker wrote:
> Really, the lookup we intended to do was a simple, plain, symbol lookup
> of "main". In an attempt to reflect this, I have tried the following
> change in inside_main_func(), and it fixes the problem at hand:
> 
> | +      enum language saved_language = current_language->la_language;
> |  
> | +      set_language (language_c);
> |        mainsym = lookup_symbol (main_name (), NULL, VAR_DOMAIN, NULL, NULL);
> | +      set_language (saved_language);
> 
> I would be more than happy to properly contribute this change, with
> comments in the code, and a changelog entry, but I see two problems
> that bother me a bit:
>   
>   1. We rely on a global variable to pass some information to a procedure,
>      and this not very good.
> 
>   2. The current change will fail to restore the saved language in case
>      an exception is raised during the call to lookup_symbol. Not really
>      that big a deal, but not very user-friendly either.
> 
> My current thoughts about each problem:
> 
>   1. It's a bit bothersome, but on the other hand lookup_symbol is
>      used everywhere. Any change in its interface would be a jumbo
>      patch. Nevertheless, I am ready to discuss this option if you
>      feel that we should bite the bullet and avoid global variables
>      as much as we can (remember about the language problems we still
>      have to tackle?). Let me know. For now, since current_language
>      is already so much widely used, I'm inclined to simply wrap
>      the call to lookup_symbol() between calls to set_language().
> 
>   2. This can easily be fixed. I think the cleanest way to do this is
>      by renaming inside_main_func() into inside_main_func_1(), and
>      write a new inside_main_func() that calls inside_main_func_1()
>      via catch_exceptions(). We can then safely wrap it between
>      calls to set_language(). But this is assuming that we decide
>      that we don't mind about concern #1 above. But I find the
>      catch exceptions interface a bit awkward. Mixing the error code
>      returned by catch_exceptions() with the return value of the
>      function called makes me flinch a bit.
> 
> What do you think?

Don't use lookup_symbol?  On David's branch there's a minsym function
for finding the minimal symbol associated with a mangled name.  I
thought it had been merged to mainline but it hasn't.  Something to do
the same for symbols would be reasonable, although rare.  Or you could
just use the minsym version, and then call find_pc_function.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer