Re: Linemap and pph

[Gabriel Charette <gchare@google.com>]

On Sat, Jul 23, 2011 at 8:51 AM, Dodji Seketeli <dodji@seketeli.org> wrote:
> 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?
>

Before using a pph, we make sure the current macro context is the same
as the one in which it was originally compiled (as far as what that
header is using from that context). So yes, sometimes we have
different pph for different C files, but it's very possible to use the
same pph for different includes in independent C files.

> 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.
>

Right this is one of the option, but as you say, potentially an
expensive change.

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

If it works, yes, I think.

>> 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.
>

Right, but no point serializing them only to filter them on input.