This is the mail archive of the
mailing list for the GDB project.
Re: [rfa:symtab] Delete broken "memory mapped objfile cache"
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 19 Jan 2004 11:49:47 -0500
- Subject: Re: [rfa:symtab] Delete broken "memory mapped objfile cache"
- References: <3FA7D202.email@example.com>
Andrew Cagney writes:
> (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
> 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?
> PS: Note that I'll also need to update the documentation
> 2003-11-02 Andrew Cagney <firstname.lastname@example.org>
> * 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.