From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22427 invoked by alias); 21 Feb 2004 20:08:17 -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 22418 invoked from network); 21 Feb 2004 20:08:16 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 21 Feb 2004 20:08:16 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AudQ7-00082R-Kr for ; Sat, 21 Feb 2004 15:08:15 -0500 Date: Sat, 21 Feb 2004 20:08:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Branch created for inter-compilation-unit references Message-ID: <20040221200814.GA28652@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00312.txt.bz2 I've just created "drow_intercu-20040221-branch". I'm going to post and commit the work I've done over the past two days, which starts at the opposite end of the problem from several approaches I've seen here in the past. At present we could safely ignore the case of partial symbol tables. The only inter-die reference that we would even examine during partial symbol table building is DW_AT_specification (and similar), for the names of DIEs whose specification is in a namespace. And generally we have a mangled name so the fallback that David checked in some weeks ago works OK. But one of the long-term goals for inter-CU support is to decrease the total size of debug information. One way to do that is separating header DIEs into separate compilation units; but another important way is to scrap DW_AT_MIPS_linkage_name. I don't want to add a new dependence on the mangled names that I would just have to clean up later. So I've begun with the partial symbol tables. I haven't actually added any inter-CU support yet; only support within a single CU for following DW_AT_specification. I load all necessary DIEs into memory before parsing any, with a couple of exceptions for speed. I build sibling and child chains like we do for full DIEs. This is where the performance cost comes in: the two big hitters are adding the DIEs I want to save to the hash table, and data cache misses from separating the loading and processing of the DIE. My focus so far has been on not increasing startup time for C (primarily) or C++ (secondarily) applications; I am within about 4% for C and about 8% for C++. I think that will be acceptable for now - there's room for about 10% improvement in other parts of GDB for C and 30% for C++, based on my profiling, and I will pursue it later. Probably before merging this code. Next will be real inter-CU support for partial symbols. Then for full symbols. My hope is that I can do both of those without perturbing the non-inter-CU path too much. GCC HEAD can already generate the necessary debug information if you want to play with it; use -gdwarf-2 -feliminate-dwarf2-dups. I expect it will be at least a few more days before GDB can read that output. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer