From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29858 invoked by alias); 22 Mar 2004 21:07:22 -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 29825 invoked from network); 22 Mar 2004 21:07:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Mar 2004 21:07:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B5Wdb-0005ag-Jq; Mon, 22 Mar 2004 16:07:11 -0500 Date: Mon, 22 Mar 2004 21:07:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa/mips] Stop backtraces when we've lost the PC Message-ID: <20040322210711.GA18944@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20040306231743.GA9379@nevyn.them.org> <404BC4B2.7000100@gnu.org> <20040308032324.GA1325@nevyn.them.org> <20040308154814.GA17012@nevyn.them.org> <20040308202557.GA28874@nevyn.them.org> <4058AFE6.8030609@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4058AFE6.8030609@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00507.txt.bz2 On Wed, Mar 17, 2004 at 03:07:02PM -0500, Andrew Cagney wrote: > Other than that, just an observation that the binary search is [already] > pretty messed up. In all likelyhood the test: > > if (pdr_pc == pc) > > will never fire and having it gains little if anything (one less > iteration VS logN extra compares). Eliminating it means cleaning up the > binary search though. Can you attach a fixme to that test indicating > that it should be eliminated. It's pretty easy to clean up the binary search instead, so I did that. > I also suspect that STARTADDR's computation can be delayed until it is > needed (the latter reference that goes with the "pathological", should > no longer occure, I think it has been moved into symbol reading. > However, leave that for the moment. I'm pretty sure I tried that, and it meant we stopped using the partial symbol table to find the beginnings of functions in some cases, leading to loud failures from heuristic_proc_start. startaddr is returned via *addrptr to the caller. > Otherwize ok, and way better than the original patch, thanks, Thanks. Here's what I'll checked in after rerunning some tests. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 2004-03-22 Daniel Jacobowitz * mips-tdep.c (non_heuristic_proc_desc): Search using the specified PC rather than the partial function start address. Use the start address to sanity check the found PDR. Index: mips-tdep.c =================================================================== RCS file: /big/fsf/rsync/src-cvs/src/gdb/mips-tdep.c,v retrieving revision 1.283 diff -u -p -r1.283 mips-tdep.c --- mips-tdep.c 17 Feb 2004 15:21:21 -0000 1.283 +++ mips-tdep.c 22 Mar 2004 20:35:32 -0000 @@ -2352,38 +2352,70 @@ non_heuristic_proc_desc (CORE_ADDR pc, C { int low, mid, high; char *ptr; + CORE_ADDR pdr_pc; low = 0; high = priv->size / 32; + /* We've found a .pdr section describing this objfile. We want to + find the entry which describes this code address. The .pdr + information is not very descriptive; we have only a function + start address. We have to look for the closest entry, because + the local symbol at the beginning of this function may have + been stripped - so if we ask the symbol table for the start + address we may get a preceding global function. */ + + /* First, find the last .pdr entry starting at or before PC. */ do { - CORE_ADDR pdr_pc; - mid = (low + high) / 2; ptr = priv->contents + mid * 32; pdr_pc = bfd_get_signed_32 (sec->objfile->obfd, ptr); pdr_pc += ANOFFSET (sec->objfile->section_offsets, SECT_OFF_TEXT (sec->objfile)); - if (pdr_pc == startaddr) - break; - if (pdr_pc > startaddr) + + if (pdr_pc > pc) high = mid; else low = mid + 1; } while (low != high); - if (low != high) + /* Both low and high point one past the PDR of interest. If + both are zero, that means this PC is before any region + covered by a PDR, i.e. pdr_pc for the first PDR entry is + greater than PC. */ + if (low > 0) + { + ptr = priv->contents + (low - 1) * 32; + pdr_pc = bfd_get_signed_32 (sec->objfile->obfd, ptr); + pdr_pc += ANOFFSET (sec->objfile->section_offsets, + SECT_OFF_TEXT (sec->objfile)); + } + + /* We don't have a range, so we have no way to know for sure + whether we're in the correct PDR or a PDR for a preceding + function and the current function was a stripped local + symbol. But if the PDR's PC is at least as great as the + best guess from the symbol table, assume that it does cover + the right area; if a .pdr section is present at all then + nearly every function will have an entry. The biggest exception + will be the dynamic linker stubs; conveniently these are + placed before .text instead of after. */ + + if (pc >= pdr_pc && pdr_pc >= startaddr) { struct symbol *sym = find_pc_function (pc); + if (addrptr) + *addrptr = pdr_pc; + /* Fill in what we need of the proc_desc. */ proc_desc = (mips_extra_func_info_t) obstack_alloc (&sec->objfile->objfile_obstack, sizeof (struct mips_extra_func_info)); - PROC_LOW_ADDR (proc_desc) = startaddr; + PROC_LOW_ADDR (proc_desc) = pdr_pc; /* Only used for dummy frames. */ PROC_HIGH_ADDR (proc_desc) = 0;