From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10125 invoked by alias); 31 Jan 2006 18:39:36 -0000 Received: (qmail 10116 invoked by uid 22791); 31 Jan 2006 18:39:35 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.197) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 31 Jan 2006 18:39:33 +0000 Received: by zproxy.gmail.com with SMTP id x3so1388816nzd for ; Tue, 31 Jan 2006 10:39:32 -0800 (PST) Received: by 10.37.20.13 with SMTP id x13mr2446105nzi; Tue, 31 Jan 2006 10:39:32 -0800 (PST) Received: by 10.37.2.63 with HTTP; Tue, 31 Jan 2006 10:39:31 -0800 (PST) Message-ID: <8f2776cb0601311039r37c73f91s1433355e18eb5e56@mail.gmail.com> Date: Tue, 31 Jan 2006 18:39:00 -0000 From: Jim Blandy To: Jim Blandy , Eirik Fuller , David Anderson , gdb-patches@sourceware.org Subject: Re: [PATCH] Use mmap for symbol tables In-Reply-To: <20060131140013.GB1249@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200601310437.k0V4bcJ7208753@quasar.engr.sgi.com> <43DEEEF2.7030202@hackrat.com> <8f2776cb0601302134w35cf9ae2v3cf03a4113fb3018@mail.gmail.com> <20060131140013.GB1249@nevyn.them.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/msg00493.txt.bz2 On 1/31/06, Daniel Jacobowitz wrote: > On Mon, Jan 30, 2006 at 09:34:38PM -0800, Jim Blandy wrote: > > On 1/30/06, Eirik Fuller wrote: > > > 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 w= ill > > > be the same. This will only waste virtual address space if the secti= ons > > > gdb would otherwise read don't form a contiguous region of the file. > > > > Actually, that's a pretty great idea. We could have the linker > > arrange to put all the debug sections together; that's easy. Then we > > could have the BFD API let GDB specify a list of sections to map. BFD > > would map the smallest contiguous region containing those sections. > > You'd get an interface that works with all files, but performs better > > when the linker does its job right. > > ... why? You're jumping through hoops here to avoid mmaping each > individual section, but I don't understand what's wrong with that. Sorry, "great idea" meant "clever way of satisfying the constraints Eirik has set"; I suggested mapping individual sections at the front, but Eirik said he wasn't interested in implementing that. "Great idea" didn't mean "this is the Way It Should Be Done." I was caught up in the moment.