From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30864 invoked by alias); 30 Jan 2002 23:26:36 -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 30809 invoked from network); 30 Jan 2002 23:26:29 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 30 Jan 2002 23:26:29 -0000 Received: from localhost.cygnus.com (cse.sfbay.redhat.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA19441; Wed, 30 Jan 2002 15:26:23 -0800 (PST) Received: (from ezannoni@localhost) by localhost.cygnus.com (8.11.2/8.11.2) id g0UNQAh02568; Wed, 30 Jan 2002 18:26:10 -0500 From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.33040.785604.720796@localhost.cygnus.com> Date: Wed, 30 Jan 2002 15:26:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix for searching for data symbols In-Reply-To: <20020119123318.A1378@nevyn.them.org> References: <20020119123318.A1378@nevyn.them.org> X-Mailer: VM 7.00 under Emacs 20.7.1 X-SW-Source: 2002-01/txt/msg00790.txt.bz2 Daniel Jacobowitz writes: > This patch fixes the problem I described in: > http://sources.redhat.com/ml/gdb/2002-01/msg00223.html > > Basically, since we use the bounds of the text segment to search for symbols > in find_pc_*, don't let them return a bogus answer for a symbol we know is > off in data land. > > OK to commit, or does anyone prefer a different approach to this? > I think it's fine. Just could you add comments with an explanation of the odd case that you described in the mail above? Thanks Elena > -- > Daniel Jacobowitz Carnegie Mellon University > MontaVista Software Debian GNU/Linux Developer > > 2002-01-19 Daniel Jacobowitz > > * symtab.c (find_pc_sect_psymtab): Do not search psymtabs for > data symbols, since we search based on textlow and texthigh. > (find_pc_sect_symtab): Likewise. > > Index: symtab.c > =================================================================== > RCS file: /cvs/src/src/gdb/symtab.c,v > retrieving revision 1.51 > diff -u -p -r1.51 symtab.c > --- symtab.c 2001/12/21 22:32:37 1.51 > +++ symtab.c 2002/01/19 17:29:09 > @@ -354,12 +354,22 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec > { > register struct partial_symtab *pst; > register struct objfile *objfile; > + struct minimal_symbol *msymbol; > > + /* If we know that this is not a text address, return failure. */ > + msymbol = lookup_minimal_symbol_by_pc_section (pc, section); > + if (msymbol > + && (msymbol->type == mst_data > + || msymbol->type == mst_bss > + || msymbol->type == mst_abs > + || msymbol->type == mst_file_data > + || msymbol->type == mst_file_bss)) > + return NULL; > + > ALL_PSYMTABS (objfile, pst) > { > if (pc >= pst->textlow && pc < pst->texthigh) > { > - struct minimal_symbol *msymbol; > struct partial_symtab *tpst; > > /* An objfile that has its functions reordered might have > @@ -370,7 +380,6 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec > section == 0) /* can't validate section this way */ > return (pst); > > - msymbol = lookup_minimal_symbol_by_pc_section (pc, section); > if (msymbol == NULL) > return (pst); > > @@ -1385,6 +1394,17 @@ find_pc_sect_symtab (CORE_ADDR pc, asect > register struct partial_symtab *ps; > register struct objfile *objfile; > CORE_ADDR distance = 0; > + struct minimal_symbol *msymbol; > + > + /* If we know that this is not a text address, return failure. */ > + msymbol = lookup_minimal_symbol_by_pc_section (pc, section); > + if (msymbol > + && (msymbol->type == mst_data > + || msymbol->type == mst_bss > + || msymbol->type == mst_abs > + || msymbol->type == mst_file_data > + || msymbol->type == mst_file_bss)) > + return NULL; > > /* Search all symtabs for the one whose file contains our address, and which > is the smallest of all the ones containing the address. This is designed