From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14273 invoked by alias); 31 Jan 2006 05:00:39 -0000 Received: (qmail 14265 invoked by uid 22791); 31 Jan 2006 05:00:38 -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; Tue, 31 Jan 2006 05:00:36 +0000 Received: from [192.168.0.241] (kagnu.hackrat.com [192.168.0.241]) by ns.hackrat.org (Postfix) with ESMTP id 66676690067; Mon, 30 Jan 2006 21:00:34 -0800 (PST) Message-ID: <43DEEEF2.7030202@hackrat.com> Date: Tue, 31 Jan 2006 05:00:00 -0000 From: Eirik Fuller User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) MIME-Version: 1.0 To: David Anderson Cc: gdb-patches@sourceware.org, Jim Blandy Subject: Re: [PATCH] Use mmap for symbol tables References: <200601310437.k0V4bcJ7208753@quasar.engr.sgi.com> In-Reply-To: <200601310437.k0V4bcJ7208753@quasar.engr.sgi.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-01/txt/msg00484.txt.bz2 > Been there, done that, with IRIX/dbx and 'just virtual address > space' was a disaster for a few big apps I don't know how dbx handles symbol tables, but in my experience the size of a symbol table needs to be within a particular power of two to exhaust virtual address space in a situation where gdb won't exhaust it anyway with malloc. A debugger which only keeps a small subset of a symbol table resident in memory (whether it uses malloc or mmap) can obviously handle much larger symbol tables, but in my experience that doesn't describe gdb. If the mmap patch is runtime optional and disabled by default, it won't make corner cases with large symbol tables any worse. I believe the right long term answer is a better symbol table format (with indexing stored on disk), even on 64 bit hosts. > The size of the text and the data can be very large indeed. > And those, as mmap, are not going to be used normally. > So are wasted virtual address space in the debugger. This suggests a simple way to complicate my mmap patch. If it can be determined beforehand what interval of the symbol table gdb is going to read in its entirety, that interval can be recorded in the BFD struct, and the first mmap call can map just that interval. That will complicate the offset calculations somewhat, but the basic approach will be the same. This will only waste virtual address space if the sections gdb would otherwise read don't form a contiguous region of the file.