Re: PCH assumes there is no information before the object

[Geoff Keating <geoffk at geoffk dot org>]

Daniel Berlin <dberlin@dberlin.org> writes:

> On Mon, 8 Sep 2003, Geoff Keating wrote:
> 
> > Daniel Berlin <dberlin@dberlin.org> writes:
> >
> > > I'm implementing PCH for the new zone collector in my spare
> > > time, and currently, PCH assumes it can simply read in the object at the correct
> > > address, and that will put everything right.
> > > This may work for ggc-page, but it won't work for ggc-simple (which has
> > > no PCH implemented), or the new zone collector.  This is because both put
> > > information before ggc allocated objects.
> > >
> > > There seems to be no way to support this without significantly modifying
> > > the PCH reading/writing machinery, which assumes it only has to write the
> > > object out.
> > >
> > > I can't even just make a table of the object header info, and write it
> > > out in the zone collector, because we'd still need to put it before each
> > > object, which we have no hook for.
> > >
> > > Geoff, have i missed something?
> >
> > I believe you can easily handle this using the current machinery.
> > ggc_pch_write_object would write out the header for the current
> > object, then the object, then enough padding to go up to the place
> > where it will write out the next object's header
> 
> However, read-in reads directly into the rti ptr, which is going to be a
> few bytes ahead of where we really want to read into.

You will have to explain this better.  It makes no sense to me.  'rti'
is used in the GGC code as an index into a fixed table of global
objects, you do not read into the table (it is fixed and usually in
read-only memory).  Nor do you read whole objects into global
variables, reading happens one pointer at a time.  The table points
directly at the objects, so why would you want to offset that by a
'few bytes'?  That would just clobber some random global memory.
There is no reason to offset the address you are reading in, that
would just mean it was computed wrongly when the PCH file was written
out.

-- 
- Geoffrey Keating <geoffk@geoffk.org>