From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26081 invoked by alias); 12 Jun 2002 23:04:55 -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 26070 invoked from network); 12 Jun 2002 23:04:54 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 12 Jun 2002 23:04:54 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C7AE93CA3; Wed, 12 Jun 2002 19:04:54 -0400 (EDT) Message-ID: <3D07D396.7020704@cygnus.com> Date: Wed, 12 Jun 2002 16:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc3) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA/mips: Use ".pdr" sections generated by GAS References: <20020611170518.GA3209@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00200.txt.bz2 > 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. Some suggested tweeks do follow, enjoy, Andrew > 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? > #define _PROC_MAGIC_ 0x0F0F0F0F > #define PROC_DESC_IS_DUMMY(proc) ((proc)->pdr.isym == _PROC_MAGIC_) > @@ -1932,6 +1934,30 @@ heuristic_proc_desc (CORE_ADDR start_pc, > return &temp_proc_desc; > } > > +struct mips_objfile_private > +{ > + bfd_size_type size; > + char *contents; > +}; > + > +/* Global used to communicate between non_heuristic_proc_desc and > + compare_pdr_entries. */ .... when doing a qsort. > +static bfd *the_bfd; Suggest ``compare_pdr_entries_abfd;''. > + /* 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)) > + { 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. */ compare_pdr_entries_abfd = sec->objfile->obfd; > + 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). Andrew