From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7175 invoked by alias); 31 Jan 2006 04:40:45 -0000 Received: (qmail 7167 invoked by uid 22791); 31 Jan 2006 04:40:44 -0000 X-Spam-Check-By: sourceware.org Received: from omx2-ext.sgi.com (HELO omx2.sgi.com) (192.48.171.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 31 Jan 2006 04:40:43 +0000 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k0V6gWf9016691; Mon, 30 Jan 2006 22:42:32 -0800 Received: from quasar.engr.sgi.com (quasar.engr.sgi.com [163.154.6.61]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0V4eXgi4554582; Mon, 30 Jan 2006 20:40:33 -0800 (PST) Received: from quasar.engr.sgi.com (localhost [127.0.0.1]) by quasar.engr.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0V4d1Tu208807; Mon, 30 Jan 2006 20:39:42 -0800 (PST) Received: (from davea@localhost) by quasar.engr.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0V4bcJ7208753; Mon, 30 Jan 2006 20:37:38 -0800 (PST) Date: Tue, 31 Jan 2006 04:40:00 -0000 From: David Anderson Message-Id: <200601310437.k0V4bcJ7208753@quasar.engr.sgi.com> To: gdb-patches@sourceware.org Subject: Re: [PATCH] Use mmap for symbol tables Cc: jimb@red-bean.com, eirik@hackrat.com 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/msg00482.txt.bz2 Jim Blandy > 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. Eirik Fuller >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. :-) > >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). Hope the following is not out of line. The phrase 'just virtual address space' should not, IMO, be uttered so cavalierly. Mapping in one glob will in some cases make gdb useless for some apps (fearless prediction). Been there, done that, with IRIX/dbx and 'just virtual address space' was a disaster for a few big apps with large value to the owners/users (when the apps needed debugging). Meaning we did exactly what Eirik Fuller proposes and had to drop back to exactly what Jim Blandy proposes. [The problem was with 32 bit address space of the debugger as it existed a few years ago.] And don't mmap in a whole core file for the same reason (not that such is being proposed, this is just another thought). David Anderson