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