From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4166 invoked by alias); 19 Nov 2003 18:19:13 -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 4159 invoked from network); 19 Nov 2003 18:19:10 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 19 Nov 2003 18:19:10 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 5A208481D5; Wed, 19 Nov 2003 10:19:10 -0800 (PST) Date: Wed, 19 Nov 2003 18:19:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFC/RFA] find_pc_sect_psymtab(): symbol table not always complete Message-ID: <20031119181910.GD1067@gnat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-11/txt/msg00396.txt.bz2 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1391 Hello, Re: http://sources.redhat.com/ml/gdb-patches/2003-11/msg00368.html The following change tweaks find_pc_sect_psymtab() to stop assuming that the symbol table will contain all symbols. So when we don't find a partial symtab containing a symbol at the same address as the minimal symbol we found, we return the symtab containing symbol which address is the closest to the given PC address. This fixes the problem reported in the message referenced above. As noted by Daniel J, the cleanest fix, in the long run, is probably to record accurate code ranges rather insted of the textlow/texthigh addresses. This is a more long term project which I wanted to tackle without the pressure of the users not being able to debug comfortably. This will be the subject of another post coming shortly. 2003-11-19 J. Brobecker * symtab.c (find_pc_sect_psymtab): Refine the search for the partial symtab corresponding to the given PC address, taking into account the fact that the symbol table might be incomplete. It has been tested on x86-linux with stabs & dwarf-2 with no regression. It has also been tested on mips-irix but on a 5.3-based version of GDB (we haven't moved to a more recent version of GDB on this platform yet, and the HEAD version is giving me some trouble that I need to sort out). Comments? OK to apply? Thanks, -- Joel --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="symtab.c.diff" Content-length: 1777 Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.122 diff -u -p -r1.122 symtab.c --- symtab.c 8 Nov 2003 00:13:03 -0000 1.122 +++ symtab.c 19 Nov 2003 18:04:15 -0000 @@ -698,6 +698,8 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec if (pc >= pst->textlow && pc < pst->texthigh) { struct partial_symtab *tpst; + struct partial_symtab *best_pst = pst; + struct partial_symbol *best_psym = NULL; /* An objfile that has its functions reordered might have many partial symbol tables containing the PC, but @@ -710,6 +712,11 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec if (msymbol == NULL) return (pst); + /* The code range of partial symtabs sometimes overlap, so + we need to check all partial symtabs and find the one that + fits better for the given PC address. We select the partial + symtab that contains a symbol which address is closest to + the PC address. */ for (tpst = pst; tpst != NULL; tpst = tpst->next) { if (pc >= tpst->textlow && pc < tpst->texthigh) @@ -721,9 +728,19 @@ find_pc_sect_psymtab (CORE_ADDR pc, asec && SYMBOL_VALUE_ADDRESS (p) == SYMBOL_VALUE_ADDRESS (msymbol)) return (tpst); + if (p != NULL) + { + if (best_psym == NULL + || SYMBOL_VALUE_ADDRESS (p) + > SYMBOL_VALUE_ADDRESS (best_psym)) + { + best_psym = p; + best_pst = tpst; + } + } } } - return (pst); + return best_pst; } } return (NULL); --LQksG6bCIzRHxTLp--