From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27444 invoked by alias); 3 Jan 2004 17:47:32 -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 27437 invoked from network); 3 Jan 2004 17:47:30 -0000 Received: from unknown (HELO mwinf0504.wanadoo.fr) (193.252.22.26) by sources.redhat.com with SMTP; 3 Jan 2004 17:47:30 -0000 Received: from takamaka.act-europe.fr (AStDenis-103-1-2-242.w81-249.abo.wanadoo.fr [81.249.112.242]) by mwinf0504.wanadoo.fr (SMTP Server) with ESMTP id A6D101000308; Sat, 3 Jan 2004 18:47:29 +0100 (CET) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id DDCDF47D62; Sat, 3 Jan 2004 21:47:26 +0400 (RET) Date: Sat, 03 Jan 2004 17:47:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC/dwarf-2] Add support for included files Message-ID: <20040103174726.GA820@gnat.com> References: <20040102072500.GS826@gnat.com> <20040102141802.GA28372@nevyn.them.org> <20040103144250.GW820@gnat.com> <1659-Sat03Jan2004183031+0200-eliz@elta.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1659-Sat03Jan2004183031+0200-eliz@elta.co.il> User-Agent: Mutt/1.4i X-SW-Source: 2004-01/txt/msg00059.txt.bz2 > I made that suggestion because it sounded like the addition you made > caused some percepted slow-down of the psymtab scan. If that is not > true, consider my reservations to be withdrawn. My original message probably wasn't clear. My concern was not exactly about performance, but rather code duplication. Currently, the task of scanning the symbols in the .debug_info data to build the psymtabs is simplified by following the DW_AT_sibling attribute. This attribute is not guaranteed to be always generated when convenient for the debugger, but it helps when it is there. In the .debug_line data, there are no such links. You really have to read byte after byte to interpret the data, and the number of bytes to read depends on the instruction. If you screw up at some point, you will end up slightly off and will therefore necessarily screw up the rest of the program (or you even fail to interpret it). My prototype patch almost duplicates a piece of code that's not really that complex, but the real problem is that it doesn't know how to recover from an error. I was trying to describe this issue for which I didn't see any simple solution, except doing some surgery in the function we currently have that reads that data and stores it into the full symtab. Hmmm, maybe the best approach to mitigate my concerns would be to actually make dwarf_decode_lines() a bit more general. Right now, its purpose is limited to storing the data it read directly into the appropriate symtabs. Modifying it to allow the us to build both symtabs but also psymtabs would make it possible to share this code. Hmmm, could I even keep it as it is? The only parts that tie this function to symtab building seem to only be from using start_subfile() and record_line() from buildsym.c. So maybe we can reuse this function directly as is: it would build subfiles, and then we could dig out the necessary information from there to build the psymtabs? I even believe we could save these subfiles in the private part of the "main" psymtab so we don't have to rescan these tables again during the psymtab to symtab conversion? Sounds like a good idea, doesn't it? Before I start experimenting, does anybody know buildsym.c enough to tell me if it would be ok to use the functions above outside of the context of building symtabs, and then to save the subfiles chain for later use during the psymtab to symtab conversion? Thanks, -- Joel