From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8646 invoked by alias); 30 Jan 2006 18:07:14 -0000 Received: (qmail 8492 invoked by uid 22791); 30 Jan 2006 18:07:14 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jan 2006 18:07:11 +0000 Received: by zproxy.gmail.com with SMTP id x3so1150539nzd for ; Mon, 30 Jan 2006 10:07:09 -0800 (PST) Received: by 10.36.79.5 with SMTP id c5mr5126090nzb; Mon, 30 Jan 2006 10:07:09 -0800 (PST) Received: by 10.37.2.63 with HTTP; Mon, 30 Jan 2006 10:07:08 -0800 (PST) Message-ID: <8f2776cb0601301007k5bccb594he33b08e84096d1a2@mail.gmail.com> Date: Mon, 30 Jan 2006 18:07:00 -0000 From: Jim Blandy To: Eirik Fuller Subject: Re: [PATCH] Use mmap for symbol tables Cc: gdb-patches@sourceware.org In-Reply-To: <43DDFC13.90909@hackrat.com> 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> <8f2776cb0601292104y1c29f4adl6e681b20cd86c177@mail.gmail.com> <43DDFC13.90909@hackrat.com> 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/msg00473.txt.bz2 That's interesting. Since GDB does make a complete pass through the symbol information to build its partial symbol tables, I would have expected that doing network I/O each time the scan touched a new page would be horrible, latency-wise. But from what you've said, it sounds like the kernel recognizes there's a linear scan going on and starts doing read-ahead, so you can do the network I/O in parallel with GDB's processing. Do I have that right? I hadn't noticed that you'd mapped the data read-only. That's an even better way of dealing with GDB bugs. It's nice to know we don't have any of that sort. :) However, doesn't that mean that changes to the data by other processes (say) would become visible to GDB? What happens when you recompile the program while GDB's running? On 1/30/06, Eirik Fuller wrote: > > 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. > > Again, this will still share memory with the block cache, so aside > > from the complexity I don't see the downside. > > I don't see the upside of making the code more complicated. The > downside of the extra complication is that it makes the patch less > likely to the point of never actually existing. :-) I know how that goes. :) > Could you be more specific about why multiple mmap regions per file are > preferable? (It might help to keep in mind that I'm using PROT_READ and > MAP_SHARED). The only downside I can see is the (relatively small) > fraction of each symbol table which is not accessed via mmap, but that > doesn't use memory, just virtual address space (if it does use memory, > that contradicts the "not accessed" part). 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).