From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20579 invoked by alias); 16 Dec 2002 15:28: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 20568 invoked from network); 16 Dec 2002 15:28:50 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Dec 2002 15:28:50 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18Nz33-0003xn-00; Mon, 16 Dec 2002 11:28:57 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18NxBW-0003Xi-00; Mon, 16 Dec 2002 10:29:34 -0500 Date: Mon, 16 Dec 2002 07:49:00 -0000 From: Daniel Jacobowitz To: Michal Ludvig Cc: GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021216152934.GA13042@nevyn.them.org> Mail-Followup-To: Michal Ludvig , GDB Patches References: <3DFBD14C.7090501@suse.cz> <20021215161924.GA2874@nevyn.them.org> <3DFDDBFA.4080406@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFDDBFA.4080406@suse.cz> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00467.txt.bz2 On Mon, Dec 16, 2002 at 02:58:18PM +0100, Michal Ludvig wrote: > Daniel Jacobowitz wrote: > >On Sun, Dec 15, 2002 at 01:48:12AM +0100, Michal Ludvig wrote: > > > >>this long patch provides a fix for a very annoying fact, that GDB on > >>x86-64 can't do backtraces from hand-optimized assembler functions (that > >>applies for example to glibc's memset, str*, etc as well as to syscall > >>wrappers). > > > >Workaround, really - just for some particular functions... > > Yes, but still better than nothing ;-) Yeah. > OK, the attached patch has a modified gdbarch.sh and regenerated > gdbarch.[ch]. > > I've also put a description into gdbint.texinfo OK, Eli will have to approve that part. > >>OK to commit to branch and mainline? > > > >I do not believe this is appropriate for the branch, at least until > >it's sat on mainline without causing problems for some time. > > It shouldn't cause any problems because all the machinery is invoked if > and only if the target allowed it, and then if a FDE isn't found for a > particular function. Typically only two or three times on x86-64 and > zero times on other archs. > > Can I put it at least to mainline? A little way to go yet. Please don't just export things from dwarf2cfi: > +/* Common Information Entry - holds information that is shared among many > + Frame Descriptors. */ > +struct cie_unit This is fine for now. > +/* Frame Description Entry. */ > +struct fde_unit > +{ So's this. > +struct fde_array > +{ > + struct fde_unit **array; > + int elems; > + int array_size; > +}; > + > +extern struct cie_unit *cie_chunks; > +extern struct fde_array fde_chunks; > + But these aren't. Add a function to link a new FDE or CIE, please. > +struct cie_unit *cie_unit_alloc (void); > +struct fde_unit *fde_unit_alloc (void); These make sense... > +void fde_chunks_need_space (void); > +int compare_fde_unit (const void *a, const void *b); But these aren't necessary if you add said function. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer