From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27780 invoked by alias); 1 Feb 2006 06:04:49 -0000 Received: (qmail 27772 invoked by uid 22791); 1 Feb 2006 06:04:49 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Feb 2006 06:04:47 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k1164gh6030086; Wed, 1 Feb 2006 01:04:42 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k1164f128431; Wed, 1 Feb 2006 01:04:42 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k1164ehD017438; Wed, 1 Feb 2006 01:04:40 -0500 Message-ID: <43E04E87.3060702@redhat.com> Date: Wed, 01 Feb 2006 06:04:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Jim Blandy CC: Eirik Fuller , gdb-patches@sourceware.org Subject: Re: [PATCH] Use mmap for symbol tables References: <20060129233630.3EFA6690067@ns.hackrat.org> <8f2776cb0601292104y1c29f4adl6e681b20cd86c177@mail.gmail.com> <43DDFC13.90909@hackrat.com> <8f2776cb0601301007k5bccb594he33b08e84096d1a2@mail.gmail.com> In-Reply-To: <8f2776cb0601301007k5bccb594he33b08e84096d1a2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00001.txt.bz2 > I'm just concerned about wasting address space. People these days do > have awfully big programs. There are executables out there in the > gigabytes (cue lurkers to share their horror stories). > Hmm? Oh! Um... Yeah, you're right, Jim. I've got users who have symbol files with over a gigabyte of debug info. Eirik, how about making this a user-specified option, from the command line? Seems like that would facilitate performance testing anyways... besides helping on platforms that don't have mmap. I noticed a side thread about gdb "scanning the symbol info linearly" on the first pass, and my thought on THAT was... what makes you think it's linear? With stabs it sure as hell isn't... And another aside -- when one of my users with the gigabyte symtabs tries to debug on a machine without enough physical memory, gdb thrashes (naturally) -- but it thrashes BAD. For all practical purposes, the initial symbol scan never terminates. That also makes me doubt that the scan is linear. One final ps -- this has been done before! It was put in, and it was taken out again. One wonders if there was a reason for taking it out. A brief glance at Changelogs suggests that it was put in in 1992, and removed again in 1996. Hmm, here's one that's poignant... Wed Jan 31 13:34:52 1996 Fred Fish * config/i386/xm-linux.h (MMAP_BASE_ADDRESS, MMAP_INCREMENT): Define to what should be reasonable values. However, apparently a bug in linux mmap prevents mapped symbol tables from working.