From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25115 invoked by alias); 4 Nov 2003 17:39:35 -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 25095 invoked from network); 4 Nov 2003 17:39:34 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 4 Nov 2003 17:39:34 -0000 Received: from [192.168.1.7] (account dberlin [192.168.1.7] verified) by dberlin.org (CommuniGate Pro SMTP 4.1.4) with ESMTP-TLS id 5303484; Tue, 04 Nov 2003 12:39:34 -0500 In-Reply-To: <3FA7D202.2050205@redhat.com> References: <3FA7D202.2050205@redhat.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: gdb-patches@sources.redhat.com From: Daniel Berlin Subject: Re: [rfa:symtab] Delete broken "memory mapped objfile cache" Date: Tue, 04 Nov 2003 17:39:00 -0000 To: Andrew Cagney X-SW-Source: 2003-11/txt/msg00043.txt.bz2 On Nov 4, 2003, at 11:21 AM, Andrew Cagney wrote: > 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). Actually, apple has it implemented and working. Maybe they'd like to share? If so, and they need that code, maybe we should keep it around for just a bit longer.