From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14645 invoked by alias); 13 Jun 2002 14:16:53 -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 14486 invoked from network); 13 Jun 2002 14:16:38 -0000 Received: from unknown (HELO nevyn.them.org) (66.19.120.41) by sources.redhat.com with SMTP; 13 Jun 2002 14:16:38 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17IVPO-0000kv-00 for ; Thu, 13 Jun 2002 10:17:06 -0400 Date: Thu, 13 Jun 2002 07:16:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA/mips: Use ".pdr" sections generated by GAS Message-ID: <20020613141706.GA1625@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20020611170518.GA3209@nevyn.them.org> <3D07D396.7020704@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D07D396.7020704@cygnus.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-06/txt/msg00213.txt.bz2 On Wed, Jun 12, 2002 at 07:04:54PM -0400, Andrew Cagney wrote: > >ECOFF debug information (mdebug) included the concept of a PDR. MIPS uses > >these for unwinding through functions, among other things. Right now we > >can > >get them from mdebug or from code inspection. But current GNU binutils > >emits ".pdr" sections instead of using the old ".mdebug" style debug info. > > > >This patch lets us read and handle the .pdr sections. It's only for > >32-bit, because for 64-bit gas currently emits only half the address. That > >I'll address later. It changes a testsuite run from 5591 calls to > >heuristic_proc_desc to 1787 calls. Most or all of those are because we > >build a heuristic procedure description if we find that we are still in the > >prologue of a function. The new ".pdr" method finds a PDR successfully for > >nearly all calls to non_heuristic_proc_desc; the others are probably > >either a > >lingering library on my system built by an older assembler, or signal/solib > >trampolines. Only 29 misses total. > > > >There's an increase in memory usage per-objfile, but no leaks, and the > >section is generally not large; for all of GDB it is only 78K. > > > >Andrew, does this look OK to you? > > Given my knowedge of PDR is limited, I 'll take your word on this. Great. Committed with comment tweaks. > >Index: mips-tdep.c > >=================================================================== > >RCS file: /cvs/src/src/gdb/mips-tdep.c,v > >retrieving revision 1.75 > >diff -u -p -u -r1.75 mips-tdep.c > >--- mips-tdep.c 9 Jun 2002 19:36:15 -0000 1.75 > >+++ mips-tdep.c 11 Jun 2002 16:54:51 -0000 > >@@ -425,6 +425,8 @@ static unsigned int heuristic_fence_post > > #define PROC_REG_OFFSET(proc) ((proc)->pdr.regoffset) > > #define PROC_FREG_OFFSET(proc) ((proc)->pdr.fregoffset) > > #define PROC_PC_REG(proc) ((proc)->pdr.pcreg) > >+/* FIXME drow/2002-06-10: If a pointer on the host is bigger than a long, > >+ this will corrupt pdr.iline. Fortunately we don't use it. */ > > #define PROC_SYMBOL(proc) (*(struct symbol**)&(proc)->pdr.isym) > > Can we simply wack these macros? Sure. That's another patch for another day, though. > >+ /* Search the ".pdr" section generated by GAS. This includes most > >of > >+ the information normally found in ECOFF PDRs. > >+ > >+ Right now GAS only outputs the address as a four-byte sequence. > >This > >+ means that we should not bother with this method on 64-bit targets > >+ until that is fixed. */ > >+ > >+ the_bfd = sec->objfile->obfd; > > I suspect the use of ``the_bfd'' global at this point was unintentional vis: > > >+ if (priv == NULL > >+ && (the_bfd->format == bfd_object > >+ && bfd_get_flavour (the_bfd) == bfd_target_elf_flavour > >+ && elf_elfheader (the_bfd)->e_ident[EI_CLASS] == ELFCLASS64)) > >+ { Nope, perfectly intentional. It has a shorter name and its value at that point is quite clear. I set it to NULL at the bottom of the if statement as you suggested. > Suggest putting the bulk of the comment explaing the ``64 bit problem'' > here where it is having an effect. > > >+ /* In general, the .pdr section is sorted. However, in the > >+ presence of multiple code sections (and other corner cases) > >+ it can become unsorted. Sort it so that we can use a faster > >+ binary search. */ I've always been a fan of commenting above conditions rather than below, but sure. > >+ qsort (priv->contents, priv->size / 32, 32, > >compare_pdr_entries); > > compare_pdr_entries_abfd = NULL; > > (I think I'll post a patch adding a gdb_qsort() function that takes a > context parameter). Good idea. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer