From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3545 invoked by alias); 19 Jan 2004 16:51:58 -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 3521 invoked from network); 19 Jan 2004 16:51:57 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 19 Jan 2004 16:51:57 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id C79801A440D; Mon, 19 Jan 2004 11:49:47 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16396.2731.710584.251473@localhost.redhat.com> Date: Mon, 19 Jan 2004 16:51:00 -0000 To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa:symtab] Delete broken "memory mapped objfile cache" In-Reply-To: <3FA7D202.2050205@redhat.com> References: <3FA7D202.2050205@redhat.com> X-SW-Source: 2004-01/txt/msg00504.txt.bz2 Andrew Cagney writes: > Hello, > > (more, somewhat perverse bcache fallout) > > The "memory mapped objfile cache" (for want of a better name) is a > technique where by GDB creates per-objfile disk backed memory mapped > caches that contain the object files symbol information. Its based on > the theory that, after each rebuild little is changed, and hence most > symbol information can be drawn from an on-disk cache, and re-read from > the object file. The lit, it turns out, supports the theory. A typical > debugging rebuild changes little in an executable. > > So why delete it? As far as I can tell: > > - it hasn't worked in >4years > - it hasn't built in >1year > - it isn't tested > > I've nothing personal against the the technique. In fact I'd like to > see a robust implementation backed by test cases and supporting > performance data. However, I strongly object to GDB having to carry > around long-ago broken code. By deleting this, we clear the decks for a > modern robust implementation (the original code appears to date back to > '92). > > Rationale: > > The original bcache was implemented using a per-object file obstack and > a finite sized table. Then in _1999_ the bcache was rewritten [fixed] > so that it could use a growable hash table. The hash table being > allocated using xmalloc. > > So? The "mapped" code, as far as I can tell, relies on all the > per-object file data being drawn from a per-object file memory-mapped > memory pool. The bcache fixes [unintentionally] broke that assumption. > The bcached data (in particular the partial symbol table) was moved to > the global memory pool making the re-mapping of a per-object file > structure anything but robust :-(. Hence, I don't believe this has > worked for >4years. > > But wait, there's more ... > > In _2003-07-12_ the bcache code was cleaned up, making the "struct > bcache" opaque. Life was good. > > So? Well, it turns out that the "mapped" code was grubbing around in > bcache internals and the change [unintentionally] broke that ability > leaving the "mapped" code unbuildable for >1year! > > ok to commit? > Andrew > > PS: Note that I'll also need to update the documentation > 2003-11-02 Andrew Cagney > > * top.h (mapped_symbol_files): Delete declaration. > * main.c (captured_main): Delete option "m" and "mapped". > * objfiles.c (mapped_symbol_files): Delete variable. > * symfile.c (symbol_file_command): Delete mmap code. > (symbol_file_add_with_addrs_or_offsets): Ditto. > (add_symbol_file_command, reread_separate_symbols): Ditto. > * objfiles.h (OBJF_MAPPED): Delete. > * objfiles.c (allocate_objfile) [USE_MMALLOC]: Delete. > (free_objfile) [USE_MMALLOC]: Ditto. > (open_existing_mapped_file): Delete function. > (open_mapped_file): Delete function. > (map_to_file): Delete function. > I verified that it doesn't build (configure --with-mmalloc). Go ahead. elena