From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1990 invoked by alias); 30 Jan 2006 05:04:29 -0000 Received: (qmail 1981 invoked by uid 22791); 30 Jan 2006 05:04:28 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.202) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jan 2006 05:04:24 +0000 Received: by zproxy.gmail.com with SMTP id x3so1028829nzd for ; Sun, 29 Jan 2006 21:04:23 -0800 (PST) Received: by 10.36.158.12 with SMTP id g12mr4627028nze; Sun, 29 Jan 2006 21:04:22 -0800 (PST) Received: by 10.37.2.63 with HTTP; Sun, 29 Jan 2006 21:04:22 -0800 (PST) Message-ID: <8f2776cb0601292104y1c29f4adl6e681b20cd86c177@mail.gmail.com> Date: Mon, 30 Jan 2006 05:04:00 -0000 From: Jim Blandy To: Eirik Fuller Subject: Re: [PATCH] Use mmap for symbol tables Cc: gdb-patches@sourceware.org In-Reply-To: <20060129233630.3EFA6690067@ns.hackrat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060129233630.3EFA6690067@ns.hackrat.org> 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-01/txt/msg00467.txt.bz2 What kind of effect does this have on performance? Is there a speed benefit to it, or is it just that it allows multiple GDB's to share memory? I believe you might as well use MAP_PRIVATE, not MAP_SHARED. The kernel will still share memory with the block cache, the pages will just be copy-on-write. You don't want bugs in GDB to corrupt your executables. I understand that it would make your BFD code more complicated, but it seems to me you want to map individual sections, not entire files.=20 Again, this will still share memory with the block cache, so aside from the complexity I don't see the downside. The last time this was brought up, there was concern about mmap's reliability and portability, but if I remember right, people weren't specific about exactly where the problems were to be expected. If this is a decent performance win, I think we should consider it, and sort out those portability issues as they arise.