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

[Joel Brobecker <brobecker at gnat dot com>]

Hello,

I just noticed this strange behavior in GDB when the name of the
application main procedure is called Main:

        (gdb) bt
        #0  process (prm_event=50) at process.adb:6
        [0] cancel
        [1] main at main.adb:6
        [2] main at b~main.adb:135

A bit of information regarding Ada, which could be useful to understand
what is happening in our case. Here is a typical Hello world in Ada95:

        with Ada.Text_IO; use Ada.Text_IO;
        
        procedure Hello is
        begin
           Put_Line ("Hello world");
        end Hello;

As you see, as opposed to C, the main procedure does not need to be
called Main in order for it to be what I will call the "user-level
main procedure". Because Ada defines a notion of elaboration, the
user-level main procedure can not be run directly when you execute
your program. GNAT does the following when building an application:
It creates a procedure which name is main(). This is the entry point
of the application which will do the following:
  - Do the program elaboration
  - Call the user-level procedure.

GNAT, just as g++ I imagine, encodes its entity names, and the way
the user-level main procedure name is encoded is simply by prepending
"_ada_" to its lowercased name. For instance, the encoded name for 
procedure Hello is "_ada_hello". And if our procedure was called Main,
it would be "_ada_main".

Suppose now that the name of the user-level main procedure was "Main",
and the user asks GDB to put a breakpoint on "main". What should GDB
understand: A breakpoint on "main", or "_ada_main"? There is no way
to tell, so GDB, via the ada language lookup function, asks the user
which one he meant with the menu shown in the transcript above.

Back to the problem at hand:

What happens is that the unwinder has be enhanced since 5.3 to make sure
not to unwind past the main procedure. Part of the machinery used to
avoid this uses the inside_main_func() function. This function in turn
relies on lookup_symbol(), which itself eventually calls the
language-specific lookup procedure (for static and global variables).

And this is when things take an unwanted turn. The conjunction of
the fact that the current language is ada, and the fact that "main"
is ambiguous as far as the ada language is concerned, causes the
unwanted multiple choice menu.

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?
-- 
Joel