From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18392 invoked by alias); 19 Apr 2004 13:21: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 18372 invoked from network); 19 Apr 2004 13:21:13 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 19 Apr 2004 13:21:13 -0000 Received: from drow by nevyn.them.org with local (Exim 4.32 #1 (Debian)) id 1BFYi1-0003Zf-Fo; Mon, 19 Apr 2004 09:21:13 -0400 Date: Mon, 19 Apr 2004 13:21:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/dwarf] Eliminate dwarf2_tmp_obstack Message-ID: <20040419132113.GB13666@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20040419031744.GA22586@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-04/txt/msg00422.txt.bz2 On Mon, Apr 19, 2004 at 01:32:38AM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > dwarf2_tmp_obstack serves as a general purpose dumping ground. After my > > previous patches, there are only two things left on it: the linked list we > > use to fudge GCC 2.95 line number tables (some day soon I think this hack > > should go away; it was primarily for the benefit of the testsuite, and was > > fixed at least as of GCC 3.1), and the block structures created in > > read_attribute_value. > > > > Both of these are clearly associated with a particular compilation unit. > > If we put them on the comp_unit_obstack, then we don't have any need for > > the global obstack any more. > > > > Since my following patches change the lifetimes of individual CUs, I felt > > this was a worthwhile cleanup. OK? > > You need to fix up the comments above free_stack_comp_unit; it's no > longer "only used during partial symbol processing". Will do. > I'd like free_stack_comp_unit renamed to free_comp_unit_obstack, so > that when I search for comp_unit_obstack, I'll also run into the calls > to make_cleanup that will free it. > > Otherwise, looks good. Mind if I don't do this one? Right now, we have: /* This cleanup function is passed the address of a dwarf2_cu on the stack when we're finished with it. We can't free the pointer itself, but release any associated storage. But on the intercu branch, it says: /* This cleanup function is passed the address of a dwarf2_cu on the stack when we're finished with it. We can't free the pointer itself, but be sure to unlink it from the cache. Also release any associated storage and perform cache maintenance. The most important thing the function does is remove a pointer from the objfile's compilation unit cache to the stack frame of the function that's ending. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer