On Thu, Mar 31, 2005 at 01:25:45PM -0800, Per Bothner wrote: > 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.
That's exactly what Geoff said. There are two relevant properties of GCed memory here: - Anything in GCed memory will be saved to the PCH - Anything in GCed memory will be overwritten by loading the PCH. There will be no references left after the PCH is loaded, unless they were living outside of GC. -- Daniel Jacobowitz CodeSourcery, LLC
