Re: [rfa:symtab] Delete broken "memory mapped objfile cache"

[Elena Zannoni <ezannoni at redhat dot com>]

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  <cagney@redhat.com>
 > 
 > 	* 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