From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30016 invoked by alias); 7 Feb 2006 22:05:37 -0000 Received: (qmail 29929 invoked by uid 22791); 7 Feb 2006 22:05:37 -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, 07 Feb 2006 22:05:36 +0000 Received: by ns.hackrat.org (Postfix, from userid 3807) id 46221690067; Tue, 7 Feb 2006 14:05:34 -0800 (PST) From: Eirik Fuller To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Use mmap for symbol tables In-Reply-To: <43DED9FA.1070305@hackrat.com> References: <20060131022330.GA24934@nevyn.them.org> <20060131033837.GA26401@nevyn.them.org> Message-Id: <20060207220534.46221690067@ns.hackrat.org> Date: Tue, 07 Feb 2006 22:05:00 -0000 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-02/txt/msg00157.txt.bz2 > One important note: you bypassed symfile_relocate_debug_section. The first time I read this I didn't fully understand it (I just hadn't really read that code yet). I think I understand it now. I also saw comments near symfile_relocate_debug_section which suggest that it won't be trivial to find a test case, contrary to my earlier response. UPS delivered my disk drive from NewEgg today, which means I should have a PowerPC GNU/Linux system soon (the disk will soon be the second disk in my G5). I might still need to pay attention to linker issues to fully explore this; I guess I'll find out soon. :-) Nonetheless I do have this revised patch. On symbol tables I use it seems to be equivalent to the one I sent earlier. I'm not resending the entire patch, just the part that affects gdb/dwarf2read.c One assumption in this revised patch which I haven't fully validated is that it makes sense to free the obstack_alloc'd buf if bfd_fetch returns a non-NULL value. I figure if symfile_relocate_debug_section returns NULL, either there were no subsequent calls to obstack_alloc, or nothing allocated by obstack_alloc after buf matters any more. I'm sure there's a cleaner way to approach this (which almost certainly requires a bit more complication in the patch), but if the mmap calls are eventually per-section in the BFD code (due to other complications in the patch) instead of covering an entire file, this piece of the patch will presumably look very different anyway. > No, probably you should just bypass the mmap if the code in that > function triggers. I think this revised patch fits that description, by deferring the call to bfd_fetch. --- gdb/dwarf2read.c.orig 2006-01-17 14:30:29.000000000 -0800 +++ gdb/dwarf2read.c 2006-02-07 12:57:46.000000000 -0800 @@ -4958,6 +4958,13 @@ if (retbuf != NULL) return retbuf; + retbuf = bfd_fetch(sectp->filepos, size, abfd); + if (retbuf != NULL) + { + obstack_free(&objfile->objfile_obstack, buf); + return retbuf; + } + if (bfd_seek (abfd, sectp->filepos, SEEK_SET) != 0 || bfd_bread (buf, size, abfd) != size) error (_("Dwarf Error: Can't read DWARF data from '%s'"),