From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6698 invoked by alias); 22 Jul 2011 20:40:05 -0000 Received: (qmail 6682 invoked by uid 22791); 22 Jul 2011 20:40:04 -0000 X-SWARE-Spam-Status: No, hits=-7.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jul 2011 20:39:46 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6MKdjgw007038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2011 16:39:45 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6MKdjAg030763; Fri, 22 Jul 2011 16:39:45 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p6MKdhag016671; Fri, 22 Jul 2011 16:39:43 -0400 From: Tom Tromey To: Gabriel Charette Cc: Diego Novillo , Lawrence Crowl , gcc@gcc.gnu.org, Collin Winter Subject: Re: Linemap and pph References: Date: Fri, 22 Jul 2011 21:15:00 -0000 In-Reply-To: (Gabriel Charette's message of "Fri, 22 Jul 2011 13:11:56 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00430.txt.bz2 >>>>> "Gabriel" == Gabriel Charette writes: Gabriel> @tromey: We have a question for you: the problem is detailed Gabriel> here and our question to you is at the bottom. Thanks! Sure. I have not followed PPH progress very closely and after reading your message I am not sure I have much to offer. I'll give it a stab anyhow. Gabriel> This is a problem in the linemap case because when we read the last Gabriel> name, we also read it's input_location (line and column) and try to Gabriel> replay that location by calling linemap_line_start (so far so Gabriel> good....). This issue is that linemap_line_start EXPECTS to be called Gabriel> with lines in increasing orders (but since the bindings are backwards Gabriel> in the chain we actually call it with lines in a decreasing order), Gabriel> the logic in linemap_line_start is such that if the line# is less then Gabriel> the previous line# it was called with, it assumes this must be a new Gabriel> file and creates a new file entry in the line_table by calling Gabriel> linemap_add (which in our case is WRONG!!). My belief is that linemap was designed to support the typical case for a C and C++ compiler. However, this is not sacrosanct; you could perhaps change the implementation to work better for your case. I suspect, though, that this won't be easy -- and also be aware of Dodji's patch series, which complicates linemap. Gabriel> In the past we have solved similar issues (caused by the backwards Gabriel> ordering), by replaying whatever it was in the correct order (before Gabriel> doing anything else), and then simply loading references using the Gabriel> pph_cache when the real ones were needed. BUT we can't do this with Gabriel> source_locations as they are a simple typedef unsigned int, not actual Gabriel> structs which are passed by pointer value... A source_location is a reference to a particular line_map. It is sort of like a compressed pointer. Gabriel> @tromey: I hear you are the person in the know when it comes down to Gabriel> linemaps, do you have any hint on how we could rebuild a valid Gabriel> line_table given we are obtaining the bindings from the last one in Gabriel> the file to the first one (that is, using pph (pre-parsed headers) Gabriel> where we are trying to restore a cached version of the parser state Gabriel> for a header)? Can you not just serialize the line map when creating the PPH? Then, when using the PPH, read the serialized line map, in order, into the current global line map. This will preserve the include chains and all the rest. Then rewrite source locations coming from the PPH to new locations from the new line map. This rewriting could perhaps even be done efficiently, say just by adding an offset to all locations -- though I am not sure, this would require some research. (It seems doable to me, though; perhaps, but not definitely, requiring some additional linemap API.) I have no idea if this is practical for you. I guess it depends on how a PPH is read in. Tom