This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linemap and pph


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]