public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dodji Seketeli <dodji@seketeli.org>
To: Gabriel Charette <gchare@google.com>
Cc: Tom Tromey <tromey@redhat.com>,
	 Diego Novillo <dnovillo@google.com>,
	 Lawrence Crowl <crowl@google.com>,
	 gcc@gcc.gnu.org,  Collin Winter <collinwinter@google.com>
Subject: Re: Linemap and pph
Date: Sat, 23 Jul 2011 17:54:00 -0000	[thread overview]
Message-ID: <m3ipqtj8ra.fsf@seketeli.org> (raw)
In-Reply-To: <CAJTZ7L+VPzfrLvnR6ZDmCd29hm2OFHo+taQfLZxDqMBgwqBg1w@mail.gmail.com>	(Gabriel Charette's message of "Fri, 22 Jul 2011 14:15:28 -0700")

Gabriel Charette <gchare@google.com> a écrit:

>> 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?
>>
>
> We were wondering about that, the problem we thought is that a pph can
> be loaded from anywhere in many different C files (which would
> generate a different linemap entry in each case I think?).

Just to make sure I understand, a given header included from two
different main C files with two different sets of macro context would
yield two macro maps with different contents anyway.  So I would believe
that these would yield two different pph, one for each C file.  Is that
correct?

For the cases where the same pph could be loaded from two different main
CUs, I'd say that in the context of a given main CU being parsed, loading
the PPH and its associated serialized line map would yield a new line
map to be inserted into the struct linemaps of the current CU.

Then, not only should the source_locations encoded by that new
de-serialized line map be rewritten (probably by modifying things like
struct linemap::to_line and struct linemap::included_from, if need be)
to fit into the source_location space of the line map set carried by the
struct linemaps of the current main CU being parsed, but the
source_locations carried by the tokens present inside the pph must also
be changed to look as if they were yielded by the newly rewritten line
map.  This is what could look expensive at first sight.

Wouldn't that address the issue of a given pph loaded by multiple main C
files?

> If there was a way to serialize the linemap entries from the LC_ENTER
> entry for the header file to the LC_LEAVE (i.e. ignoring builtins,
> command line, etc.)

I believe all the builtins have the same source_location, which is the
BUILTIN_LOCATION constant.  As for command line options, I believe they
get the location UNKNOWN_LOCATION.  So I would think these should not be
a problem when de-serializing the line map.

-- 
		Dodji

  parent reply	other threads:[~2011-07-23 15:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-22 20:40 Gabriel Charette
2011-07-22 21:15 ` Tom Tromey
2011-07-22 22:12   ` Gabriel Charette
2011-07-23  5:46     ` Tom Tromey
2011-07-23 17:54     ` Dodji Seketeli [this message]
2011-07-25 19:34       ` Gabriel Charette
2011-07-25 22:55         ` Gabriel Charette
2011-07-26 14:46           ` Dodji Seketeli
2011-07-26 18:49             ` Gabriel Charette
2011-07-26 22:54               ` Gabriel Charette
2011-07-27 10:11                 ` Dodji Seketeli
2011-07-27 14:17                   ` Gabriel Charette
2011-07-27 14:26                     ` Dodji Seketeli
2011-07-27 14:51                       ` Gabriel Charette
2011-07-27 15:45                         ` Dodji Seketeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3ipqtj8ra.fsf@seketeli.org \
    --to=dodji@seketeli.org \
    --cc=collinwinter@google.com \
    --cc=crowl@google.com \
    --cc=dnovillo@google.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gchare@google.com \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).