From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17587 invoked by alias); 31 Jan 2006 03:31:11 -0000 Received: (qmail 17575 invoked by uid 22791); 31 Jan 2006 03:31:10 -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; Tue, 31 Jan 2006 03:31:08 +0000 Received: from [192.168.0.241] (kagnu.hackrat.com [192.168.0.241]) by ns.hackrat.org (Postfix) with ESMTP id 65ADE690067; Mon, 30 Jan 2006 19:31:07 -0800 (PST) Message-ID: <43DED9FA.1070305@hackrat.com> Date: Tue, 31 Jan 2006 03:31:00 -0000 From: Eirik Fuller User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Use mmap for symbol tables References: <20060129233630.3EFA6690067@ns.hackrat.org> <20060131022330.GA24934@nevyn.them.org> In-Reply-To: <20060131022330.GA24934@nevyn.them.org> 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-01/txt/msg00480.txt.bz2 > One important note: you bypassed symfile_relocate_debug_section. I'll look at it. It hasn't yet been an issue in anything I've used my gdb mmap patches with, but offhand I'd expect it should be easy to find something that does trip over that. I can watch attempts to write back to the readonly mmap region from gdb, and maybe cobble together some malloc glue which provides the illusion of copy on write. Or maybe just convince myself that MAP_PRIVATE is the right answer (but it might be better to keep PROT_READ, just to really keep track of what gdb needs to modify and what it doesn't need to modify). > you'll get better hot-cache performance because two consecutive > sessions can do DWARF processing on pages already read in That sounds similar to my earlier observation about the memory footprint of concurrent gdb sessions on the same symbol table, but if I understand correctly you're saying that even consecutive (non-overlapping) gdb sessions can benefit if pages stay in the page cache. I think that was visible to some extent in the comparative timing between read and mmap for the case where the symbol table was already in the page cache (mmap was roughly two seconds faster, 43 versus 45).