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:

> From what I understand, the source_locations allocated for
> everything in a given set of headers (from the LC_ENTER for the
> header in the line_table up to, and including everything in between,
> the corresponding LC_LEAVE) is dependent on only one thing; the
> value of line_table->highest_location when the header was inserted

The source_location handed out by a given line map is dependant on
three things:

1/ The line_map::start_location.  For a given map, this one equals
line_table->highest_location + 1, because at the time the line map is
created, its line_map::start_location must be greater than the highest
source_location handed out by any line map previously created.  At any
point in time, line_table->highest_location equals the
line_map::start_location of the lastly created line_map.  This is part
of the monotonically increasing property of source_location we were
talking about earlier.

2/ The line number of the location

3/ The column number of the location

> (i.e. if in two different contexts we happen to have the same
> line_table->highest_location when inserting header A.h, all of the
> tokens for A.h in each context will have the same source_location).

Each token coming from a given A.h will have a different
source_location, as they will presumably have a different {line,column}
pair.

If in two different contexts we happen to have the same
line_table->highest_location, the line_map::start_location of the two
different line maps of the two different A.hs will be equal, though.
 
> If the previous statement is true, then we calculate an offset
> between the line_table->highest_location as it was in the serialized
> version of the header and as it is in the C file in which we are
> about to de-serialize the line table.
>
> We then need to update some things based on that offset:

[...]

It seems to me that you could just set the line_map::start_location of
the de-serialized map for the current portion of A.h to the current
line_table->highest_location of the main CU your are currently parsing
(i.e, just forget about the serialized line_table->highest_location
into account.  Actually I would think that it's unnecessary to
serialize the line_table->highest_location) + 1.

Then you should also set the de-serialized line_map::to_line to the
current line in your context.  Then you should add that line map to
the current line_table and set line_table->highest_location to the
line_map::start_location you have just computed.

Then, assign the source_location of each token that belongs to that
de-serialized map to a source_location that is handed out by your new
linemap_position_for_line_and_column, with de-serialized map passed in
argument.  This is where you would progress "backward" in the token
stream, for that given map.

Then somehow, when you need to suck in a new pph (so this time you are
going downward in the stream again), just start this dance of
de-serializing the map for that new pph, updating its properties,
adding it to line_table, and setting the source_location of the tokens
coming for that pph again.

-- 
		Dodji


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