From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 676 invoked by alias); 7 Oct 2003 00:15:45 -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 653 invoked from network); 7 Oct 2003 00:15:44 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 7 Oct 2003 00:15:44 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A6fVv-0004Mn-EQ; Mon, 06 Oct 2003 20:15:43 -0400 Date: Tue, 07 Oct 2003 00:15:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] lookup problem in blockframe.c:inside_main_func() Message-ID: <20031007001543.GA16602@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20031006233728.GB933@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031006233728.GB933@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00142.txt.bz2 [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