From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21924 invoked by alias); 10 Oct 2003 20:57:14 -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 21905 invoked from network); 10 Oct 2003 20:57:10 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 10 Oct 2003 20:57:10 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 02013D2D29; Fri, 10 Oct 2003 13:57:08 -0700 (PDT) Date: Fri, 10 Oct 2003 20:57:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFC] lookup problem in blockframe.c:inside_main_func() Message-ID: <20031010205708.GY933@gnat.com> References: <20031006233728.GB933@gnat.com> <20031007001543.GA16602@nevyn.them.org> <20031007002422.GF933@gnat.com> <20031007014942.GA18589@nevyn.them.org> <20031007021431.GH933@gnat.com> <20031009142754.GD29621@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OFj+1YLvsEfSXdCH" Content-Disposition: inline In-Reply-To: <20031009142754.GD29621@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-10/txt/msg00381.txt.bz2 --OFj+1YLvsEfSXdCH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 332 > > 2003-10-06 J. Brobecker > > > > * blockframe.c (inside_main_func): No longer use symbol_lookup() > > to lookup the main function symbol. > > This is OK. Thank you Daniel. Attached is what I ended up commiting (added the dated comment - let me know if you'd like to see it reworked). -- Joel --OFj+1YLvsEfSXdCH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="blockframe.c.diff" Content-length: 2365 Index: blockframe.c =================================================================== RCS file: /cvs/src/src/gdb/blockframe.c,v retrieving revision 1.80 diff -u -p -r1.80 blockframe.c --- blockframe.c 14 Sep 2003 16:32:12 -0000 1.80 +++ blockframe.c 10 Oct 2003 20:21:02 -0000 @@ -83,22 +83,35 @@ deprecated_inside_entry_file (CORE_ADDR int inside_main_func (CORE_ADDR pc) { + struct minimal_symbol *msymbol; + if (pc == 0) return 1; if (symfile_objfile == 0) return 0; + msymbol = lookup_minimal_symbol (main_name (), NULL, symfile_objfile); + /* If the addr range is not set up at symbol reading time, set it up now. This is for DEPRECATED_FRAME_CHAIN_VALID_ALTERNATE. I do this for coff, because it is unable to set it up and symbol reading time. */ - if (symfile_objfile->ei.main_func_lowpc == INVALID_ENTRY_LOWPC && - symfile_objfile->ei.main_func_highpc == INVALID_ENTRY_HIGHPC) + if (msymbol != NULL + && symfile_objfile->ei.main_func_lowpc == INVALID_ENTRY_LOWPC + && symfile_objfile->ei.main_func_highpc == INVALID_ENTRY_HIGHPC) { - struct symbol *mainsym; + /* brobecker/2003-10-10: We used to rely on lookup_symbol() to search + the symbol associated to the main function. Unfortunately, + lookup_symbol() uses the current-language la_lookup_symbol_nonlocal + function to do the global symbol search. Depending on the language, + this can introduce certain side-effects, because certain languages + such as Ada for instance may find more than one match. So we prefer + to search the main function symbol using its address rather than + its name. */ + struct symbol *mainsym + = find_pc_function (SYMBOL_VALUE_ADDRESS (msymbol)); - mainsym = lookup_symbol (main_name (), NULL, VAR_DOMAIN, NULL, NULL); if (mainsym && SYMBOL_CLASS (mainsym) == LOC_BLOCK) { symfile_objfile->ei.main_func_lowpc = @@ -111,8 +124,6 @@ inside_main_func (CORE_ADDR pc) /* Not in the normal symbol tables, see if "main" is in the partial symbol table. If it's not, then give up. */ { - struct minimal_symbol *msymbol - = lookup_minimal_symbol (main_name (), NULL, symfile_objfile); if (msymbol != NULL && MSYMBOL_TYPE (msymbol) == mst_text) { struct obj_section *osect --OFj+1YLvsEfSXdCH--