From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15373 invoked by alias); 16 Feb 2004 15:05:14 -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 15353 invoked from network); 16 Feb 2004 15:05:14 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Feb 2004 15:05:14 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 8778C1A448A; Mon, 16 Feb 2004 10:01:04 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16432.56112.64946.492536@localhost.redhat.com> Date: Mon, 16 Feb 2004 15:05:00 -0000 To: Daniel Jacobowitz Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: RFA: Don't use obsavestring in dwarf2read In-Reply-To: <20040208044115.GD13033@nevyn.them.org> References: <20040112015726.GA7151@nevyn.them.org> <20040202182218.GA3405@nevyn.them.org> <16418.39156.566837.685666@localhost.redhat.com> <20040205194821.GA30363@nevyn.them.org> <16418.43222.486879.784465@localhost.redhat.com> <20040205204756.GA2465@nevyn.them.org> <16418.52967.149289.557083@localhost.redhat.com> <20040208044115.GD13033@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00399.txt.bz2 Daniel Jacobowitz writes: > > +/* A note on memory usage: at the present time, this code reads the debug > + info sections into the objfile's objfile_obstack. A definite improvement > + for startup time, on platforms which do not emit relocations for debug > + sections, would be to use mmap instead. > + > + In either case, the sections should remain loaded until the objfile is > + released, and pointers into the section data can be used for any other > + data associated to the objfile (symbol names, type names, location expressions > + to name a few). */ > + There is a similar comment right before the dwarf2_pinfo structure, can you somehow either unify the two or 'link' them together? Both peices of information should be available together. Actually having this comment just before an ifdeffed out section of code, makes me wonder if it won't be overlooked. > #if 0 > /* .debug_info header for a compilation unit > Because of alignment constraints, this structure has padding and cannot > @@ -2665,8 +2675,7 @@ dwarf2_add_field (struct field_info *fip > attr = dwarf2_attr (die, DW_AT_name, cu); > if (attr && DW_STRING (attr)) > fieldname = DW_STRING (attr); > - fp->name = obsavestring (fieldname, strlen (fieldname), > - &objfile->objfile_obstack); > + fp->name = fieldname; > Can you please add a clear comment above the assignment about filename being on the obstack? > /* Change accessibility for artificial fields (e.g. virtual table > pointer or virtual base class pointer) to private. */ > @@ -2697,11 +2706,9 @@ dwarf2_add_field (struct field_info *fip > /* Get physical name. */ > physname = dwarf2_linkage_name (die, cu); > > - SET_FIELD_PHYSNAME (*fp, obsavestring (physname, strlen (physname), > - &objfile->objfile_obstack)); > + SET_FIELD_PHYSNAME (*fp, physname ? physname : ""); same here > FIELD_TYPE (*fp) = die_type (die, cu); > - FIELD_NAME (*fp) = obsavestring (fieldname, strlen (fieldname), > - &objfile->objfile_obstack); > + FIELD_NAME (*fp) = fieldname; and here > } > else if (die->tag == DW_TAG_inheritance) > { > @@ -2869,8 +2876,7 @@ dwarf2_add_member_fn (struct field_info > > /* Fill in the member function field info. */ > fnp = &new_fnfield->fnfield; > - fnp->physname = obsavestring (physname, strlen (physname), > - &objfile->objfile_obstack); > + fnp->physname = physname ? physname : ""; and here .... and everywhere else? otherwise ok.