From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2064 invoked by alias); 1 Feb 2006 18:11:22 -0000 Received: (qmail 2055 invoked by uid 22791); 1 Feb 2006 18:11:21 -0000 X-Spam-Check-By: sourceware.org Received: from ns.hackrat.net (HELO ns.hackrat.org) (157.22.130.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Feb 2006 18:11:19 +0000 Received: from [192.168.0.43] (etch.hackrat.com [192.168.0.43]) by ns.hackrat.org (Postfix) with ESMTP id 806A0690067; Wed, 1 Feb 2006 10:11:17 -0800 (PST) Message-ID: <43E0F9B8.4040603@hackrat.com> Date: Wed, 01 Feb 2006 18:11:00 -0000 From: Eirik Fuller User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Jim Blandy Cc: David Anderson , gdb-patches@sourceware.org Subject: Re: [PATCH] Use mmap for symbol tables References: <200601310437.k0V4bcJ7208753@quasar.engr.sgi.com> <43DEEEF2.7030202@hackrat.com> <8f2776cb0601302134w35cf9ae2v3cf03a4113fb3018@mail.gmail.com> <20060131140013.GB1249@nevyn.them.org> <8f2776cb0601311039r37c73f91s1433355e18eb5e56@mail.gmail.com> In-Reply-To: <8f2776cb0601311039r37c73f91s1433355e18eb5e56@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00005.txt.bz2 > Sorry, "great idea" meant "clever way of satisfying the constraints > Eirik has set"; I thought "great idea" seemed a bit over the top when I first read it; "nifty hack" might be a bit closer. :-) > I suggested mapping individual sections at the front, but Eirik said > he wasn't interested in implementing that. I'm not sure I put it that strongly. I certainly haven't implemented it yet, because I prefer the simplest approach which works. Given a choice between a simple patch which works well for my problem space and doing without because I don't have the energy to complicate things enough to avoid wasting some virtual address space (a minor amount really, in the particular context I was operating in), the simple patch won. This discussion has also included the more general issue of whether using mmap is the right answer in the first place. If the answer to that more fundamental question is no, the other details really don't much matter. :-) I think I've already convinced myself (with much appreciated help from this thread) that making mmap the default way of reading symbol tables in GDB is probably not the right answer. I would even go so far as to say I'm not convinced there are enough people who can benefit from it to make it a standard part of GDB (although I haven't given up on that yet). But if nothing else, posting my patch at least gives others in similar situations (huge symbol tables which "never" disappear with a strong likelihood of multiple concurrent GDB sessions on the same symbol table) an alternative to filling up their swap space. Perhaps the best argument in favor of including this in the distribution, in some fashion (with or without the extra complication to conserve address space), disabled by default, is that not everyone who might benefit from this approach pays attention to this mailing list. If it would substantially improve the chances of including mmap support (optional at both compile time and runtime) in the GDB distribution, I'd be willing to take a crack at adding the complication to mmap only stuff that GDB reads anyway. And either way I still need to look at the symfile_relocate_debug_section question, and fill in the gaps (the configure hooks and documentation and test cases). Plus I intend to perform more timing experiments (including symbol tables on local disk).