From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28076 invoked by alias); 4 Dec 2009 23:13:12 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 28066 invoked by uid 22791); 4 Dec 2009 23:13:11 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Paul Pluzhnikov Cc: Daniel Jacobowitz , Cary Coutant , Dodji Seketeli , "GDB\/Archer list" Subject: Re: [RFC] Proposal for a new DWARF name index section References: <4A7FE28D.4050901@redhat.com> <4A8D8868.3010302@redhat.com> <20091202051717.GA24978@caradoc.them.org> <20091202173518.GA13838@caradoc.them.org> <20091202193852.GA23631@caradoc.them.org> <8ac60eac0912021746g3cc9b543j1b175cf80b433705@mail.gmail.com> Reply-To: Tom Tromey Date: Fri, 04 Dec 2009 23:13:00 -0000 In-Reply-To: <8ac60eac0912021746g3cc9b543j1b175cf80b433705@mail.gmail.com> (Paul Pluzhnikov's message of "Wed, 2 Dec 2009 17:46:33 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q4/txt/msg00080.txt.bz2 >>>>> "Paul" == Paul Pluzhnikov writes: Paul> FWIW, I've used the following approach on a previous product X: Paul> - As new binary is detected, a copy of X is invoked to parse all Paul> the needed debug info into internal form and written to a cache file. Paul> - Once the copy exits, the cache file is directly mmap()ed by X. Paul> - Cache files older than 1 week, and cache files prepared from Paul> binaries which no longer exist in their original location are Paul> pruned to keep cache size down. Thanks. FWIW, gdb used to have a caching scheme like that. It has been a long time, so I don't remember the details... I know that Jan had a reimplementation of it last year, but found that it wasn't a real performance win. I don't recall why. If we can get acceptable performance without a cache, then I think that would be preferable. One trouble with caching is that it is still slow the first time. So far, it is clear that we can improve performance. It is less clear whether we can improve it enough, but I'm working on finding out. Paul> One of our typical usage scenarios is a tiny executable linked with Paul> 1000+ C++ shared libraries. Simply re-running the test a second time Paul> in a row in GDB takes 1+ minutes, as GDB discards and re-reads the Paul> debug info for each solib (it used to take 6+ minutes before my dwarf Paul> mmap changes). It seems to me that we could be a bit smarter about objfile lifetimes. I think this will probably be important for good performance in the multi-inferior case. Consider the classic "make check" example. If we aggressively discard objfiles as we do now, in this case we will be reading and throwing away the debuginfo for gcc/cc1/etc for every object built by make... ugh. Tom