From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8758 invoked by alias); 11 Oct 2004 01:46:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8748 invoked from network); 11 Oct 2004 01:46:40 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 11 Oct 2004 01:46:40 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i9B1kYRu031913 for ; Sun, 10 Oct 2004 21:46:35 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i9B1kDr27665; Sun, 10 Oct 2004 21:46:13 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CD20228CD; Sun, 10 Oct 2004 21:45:51 -0400 (EDT) Message-ID: <4169E5CF.4070201@gnu.org> Date: Mon, 11 Oct 2004 06:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20041009 MIME-Version: 1.0 To: Daniel Berlin Cc: Jason Molenda , Daniel Jacobowitz , Nick Savoiu , gdb@sources.redhat.com Subject: Re: Debugging a large program References: <20041008121611.A90098@molenda.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg00276.txt.bz2 > >> >> Andrew's approach is much cooler, > Which is probably why i suggested exactly that years ago :) I remember the mmap stuff but not much else. At one stage I ran the basics past Jim but he didn't mention your stuff (just described it has hard to impossible). Do you have a URL. >> GDB needs to find ways to achieve (assuming co-operation from GCC and >> BFD) an initial: >> >> - process symtab sections (for address ranges) - O() >> >> and then when a symbol is requested: >> >> - lookup symbol - O(log ()) * O() for first time >> (better?); O(1) for re-searches Right now, I think this is the most important aspect. It establishes an absolute bound on the performance. No matter what is done, it needs to be measured against that. > The cooperation you need is a bit more than just debug_pubnames, pubtypes, and debug_aranges though (so that info functions and whatnot still worked like it does now), but nobody has ever asked any gcc guys to implement it for them (heck, i'd be happy to if you guys put together a definitive list of things you need, and proposed any new sections to the dwarf3 mailing list). > > If you don't care about info functions output, tab completion of names, or are willing to live with them only showing "public" symbols, i believe you could implement this stuff now. > > bfd's window stuff is currently undefined unless want_mmap is set to true (by the configure option --with-mmap, the default is false, it seems). > You need that to be able to just get pieces of the section. > > It looks like it has a non-mmap fallback implemented in bfdwin.c, but "bfd_generic_get_section_contents_in_window" aborts if you don't have USE_MMAP set. > > So uh, just wake me someone gets all the bfd stuff sorted out, and you guys figure out what you need more than what you've got to do this in the way you want it done, and i'll happily help propose these things on the dwarf3 reflector/implement them for gcc. Andrew