From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28230 invoked by alias); 3 Jan 2004 14:42:55 -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 28173 invoked from network); 3 Jan 2004 14:42:54 -0000 Received: from unknown (HELO mwinf0304.wanadoo.fr) (193.252.22.28) by sources.redhat.com with SMTP; 3 Jan 2004 14:42:54 -0000 Received: from takamaka.act-europe.fr (AStDenis-103-1-2-242.w81-249.abo.wanadoo.fr [81.249.112.242]) by mwinf0304.wanadoo.fr (SMTP Server) with ESMTP id 6DD3FA80413E for ; Sat, 3 Jan 2004 15:42:53 +0100 (CET) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 0815747D62; Sat, 3 Jan 2004 18:42:50 +0400 (RET) Date: Sat, 03 Jan 2004 14:42:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: [RFC/dwarf-2] Add support for included files Message-ID: <20040103144250.GW820@gnat.com> References: <20040102072500.GS826@gnat.com> <20040102141802.GA28372@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040102141802.GA28372@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2004-01/txt/msg00051.txt.bz2 On Fri, Jan 02, 2004 at 09:18:02AM -0500, Daniel Jacobowitz wrote: > Well, the question is whether this works well enough. Things _are_ in > these files - DW_AT_decl_file points to them. Do we need to also put > things into the proper psymtabs? At this point, I don't see anything else that we need. > Otherwise the approach seems reasonable. Thanks. I can submit a proper patch soon, but there is Eli's suggestion, though: Eli Zaretskii wrote: > How about if we only do that scan when the file name is not found in > the partial symbols, i.e. just before GDB is about to give up and > report the file as nonexistent? Assuming that the cases you have in > mind are rare, this would mean faster operation in most cases. I am a bit relunctant to go that way, because I think the current approach of using a half-baked psymtabs to hold include files is a bit too adhoc for my taste. Adding an extra step after having scanned the psymtab list to iterate over all objfiles, and re-partially scan the debugging information seems to be going one step further in ``legitimizing'' this adhoc approach. If I were to add this extra step, I would rather introduce a separate data structure for include files, and then we could build the list of include files on-the-fly as you suggest when scanning this list. Trouble is, we may have also made some assumptions in several places of GDB's code that the psymtab list contains all source files. I suspect that the extra step you are suggesting will not affect most of the instances of the code scaning the psymtab list, so only a few of them will in fact need to be updated. But I'd rather fix the build_psymtab phase. It seems a bit of effort for a gain that we haven't measured. I would suggest going the simple way first and re-think it if the performance becomes noticeably worse. If somebody has a large app like mozilla that he can use to do some measurement, I would sure appreciate how much slower it is to startup with the patch I posted. (Eli, I don't know about C++, but you have a good point about lex & yacc code) Let me know what you all think. Thanks, -- Joel