This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PCH versus --enable-mapped-location
Geoff Keating wrote:
>> * Any source_location values handed out before the #include
that restores the gch will become invalid. They will be re-mapped
to that in the pre-compiled header. Presumably that's ok - there's
no declartions or expressions in the main file at that point, or
the restore would have failed. Any declarations that are <builtin>
or in the <command line> will presumably be the same either way.
Another way of putting this is that source_location values should be in
GCed memory. I think they all are, certainly all declarations and macro
definitions are.
I think you're misunderstanding my concern. The issue is when we're
processing a .c file normally we generate source_location cookies
for <builtin>, <command line>, and any tokens until we process the
#include that restores the pch. At that point we (need to) restore
the line number saved in the pch. Any source_location cookies
that we've handed out up until then become invalid, because they
refer to a line_table that has been replaced. My point is that
presumably it doesn't matter, since the source_location cookies
and declarations corresponing to <builtin> and <command line>
should match, when compared with those at pch-generation time.
The ones that don't match are any source_location cookies for
tokens in the main file itself. However, they should just be
tokens for white space, comments, and the initial #include that
triggers the pch-restoration, and there should be nothing except
garbage that use those now-invalid source_locations.
Custom restore code is problematic because it means doing something at
PCH restore time, and so it's always speed-critical. Changing two
pointers is not too expensive (especially if you can arrange for those
pointers to be on the same page), but copying a data structure
(especially a large one) is not a good idea.
Then there's something I'm not getting. The data in the line number
has to be saved in the gch file, read in, and "patched". This is
true whether the data is part of the garbage collected heap, and
so gets automatically reatored, or whether it uses special code, like
the dependencies.
I can see if yoyu're memory-mapping you want to do as much reading
implicitly using mapping, rather than explicit reading. Is that it?
The line_map entries contain a filename pointer plus various
other non-pointer fields. It might be reasonable to split those
into two separate arrays: an array of (const char*) and an array
of non-relocatable data. I don't know if that would be helpful.
It would means fixing client code that references map entries
directly.
--
--Per Bothner
per@bothner.com http://per.bothner.com/