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

[Andrew Cagney]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20031104/8b5bd3b3/attachment.ksh>