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:

>>>
>>> Hence, given that they only depend on start_location, I just have to
>>> calculate an offset between the serialized start_location and the
>>> start_location as it would be (highest_location + 1) in the C file
>>> including the header, and offset all of the source_locations on each
>>> token coming from the pph (without even needing to recalculate them!).
>>>
>>
>> That could work. ÂBut then you'd need to do something for a map encoding
>> the locations of tokens coming from the pph to appear in line_table,
>> right? ÂOtherwise, at lookup time, (when you want to find the map that
>> matches the source_location of a token coming for that pph), you'll be
>> in trouble. ÂI am saying this b/c you are not calling linemap_line_start
>> anymore. ÂAnd that function was the one that was including the said map
>> to line_table. ÂAnd the map still must be inserted into line_table
>> somehow.
>>
>
> The lookup, from what I understand, only depends on the line_map
> entries for the header to be present,

Exactly.  The line_map need to be present inside line_table->maps, so
you need to insert it in there somehow.  It wasn't clear to me from my
reading of your previous messages.

[...]

>>> Doing it this way (with the offset) I would read in all the tokens and
>>> linemap entries inherited from that header and it's underlying include
>>> tree, thus no need to be tricky about inserting line tables for the
>>> header's included file, as they are part of the header's serialized
>>> line_table by recursion (a pph'ed header can include other pph'ed
>>> header),
>>
>> This is what I am not sure to understand. ÂThere is only one line table
>> per CU. ÂThe headers included by the CU generate instances of struct
>> line map that are inserted into the line table of the CU. ÂSo I don't
>> understand what you mean by "header's serialized line_table", as I don't
>> think there is such a thing as a header's line_table.
>
> What I mean by "serialized header line_table" is the serialized
> version of the line_table as it was when were done parsing the header
> being pph'ed.

OK.  Please note that you don't necessarily need to serialize the entire
line_map at the parsing point of the pph.  I believe that just
serializing the line maps of the pph'ed header should suffice.  How to
determine them is another question. :-)

> I would then de-serialize that and insert it's line_map entries in the
> C file's line_table, doing the necessary offset adjustements in the
> process (and updating all other line_table variables like
> highest_location that would have changed if we had actually called the
> linemap functions)

OK.  We are on the same page now.  Thanks.

-- 
		Dodji


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