From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12610 invoked by alias); 7 Apr 2004 16:05:01 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12528 invoked from network); 7 Apr 2004 16:04:53 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 7 Apr 2004 16:04:53 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i37G4rWB009882 for ; Wed, 7 Apr 2004 12:04:53 -0400 Received: from zenia.home.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 i37G4pj13315; Wed, 7 Apr 2004 12:04:51 -0400 To: Joel Brobecker CC: Daniel Jacobowitz , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFC/dwarf-2] Add support for included files From: Jim Blandy Date: Wed, 07 Apr 2004 16:05:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00168.txt.bz2 Picking up a dropped thread from January: http://sources.redhat.com/ml/gdb-patches/2004-01/msg00015.html Some comments: It's fine for GDB core code to assume that the psymtabs mention every source file in the program. They're supposed to. The whole purpose of the psymtabs is to act as an index for the full symbol information, so that without taking the time/memory to read full symbols, we can at least find the compilation unit we do need to read. If that index doesn't mention a source file, then it's incomplete. I'm not too enthusiastic about Eli's suggestion that we put off scanning for source file names until we get a filename we can't find. It would help: we can find source files most of the time already, and when the second scan was needed, it wouldn't be any more work than what Joel's proposing we do every time. But it's adding a third phase to debug reading; I'd prefer to fix this problem without architectural changes like that, if it's practical. The original motivation for introducing psymtabs at all was speed: GDB's startup time was, believe it or not, CPU-bound. By constructing only partial symtabs at startup time, we avoided parsing types (essentially). How does this patch affect the time GDB takes to start up on itself? (If you had some monster program lying around, that would be better, but if all we've got is a brute...) If it makes a big speed difference, then let's try ignoring DW_LNE_define_file, not scanning the line number program, and just entering the files given in the file_names table as psymtabs. GCC doesn't generate DW_LNE_define_file. If that is much faster, then I think it'll be okay. (It's interesting to note that, since DW_LNE_define_file exists, the mechanisms Dwarf 3 provides for "accelerated access" are insufficient: there's no way to build a complete index of source file names without reading the line tables.)