From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15902 invoked by alias); 6 Oct 2003 23:37:32 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15892 invoked from network); 6 Oct 2003 23:37:30 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 6 Oct 2003 23:37:30 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 21772D2D29; Mon, 6 Oct 2003 16:37:29 -0700 (PDT) Date: Mon, 06 Oct 2003 23:37:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFC] lookup problem in blockframe.c:inside_main_func() Message-ID: <20031006233728.GB933@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-10/txt/msg00139.txt.bz2 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