From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14435 invoked by alias); 1 Feb 2006 17:52:05 -0000 Received: (qmail 14384 invoked by uid 22791); 1 Feb 2006 17:52:04 -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 17:52:02 +0000 Received: from [192.168.0.43] (etch.hackrat.com [192.168.0.43]) by ns.hackrat.org (Postfix) with ESMTP id 3CB97690067; Wed, 1 Feb 2006 09:52:00 -0800 (PST) Message-ID: <43E0F532.3060901@hackrat.com> Date: Wed, 01 Feb 2006 17:52:00 -0000 From: Eirik Fuller User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Mark Kettenis Cc: Jim Blandy , 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> <43DE61FD.2090309@hackrat.com> <8f2776cb0601301411j17219c9en74881de2489ad129@mail.gmail.com> <43DEB182.4020804@hackrat.com> <200601312147.k0VLlrxj011443@elgar.sibelius.xs4all.nl> In-Reply-To: <200601312147.k0VLlrxj011443@elgar.sibelius.xs4all.nl> 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/msg00003.txt.bz2 > So you'll have to check at runtime whether mmap is possible and if it > fails fall back on the old code that simply reads the file. My patch does that. The compile time conditionals are, um, still in the future, but the runtime check is, if mmap fails, act as though the call had never occurred. Disabling the mmap code through a runtime config option is similar. The trick is to not get rid of the fallback (the original malloc/seek/read code); each chunk of the patch which adds a call to mmap test the return value and falls through to the original code if mmap fails. The calling code doesn't care whether the mmap syscall failed, or mmap wasn't even called because of a config option. It wouldn't be all that hard to handle mmap failures by disabling mmap; that would eliminate the overhead of repeated mmap failures (replace it by the overhead of repeated checks of the runtime config option value; I assume that overhead is negligible).