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: PCH bit me


Alan Modra <amodra@bigpond.net.au> writes:

> On Wed, Nov 26, 2003 at 11:29:50PM -0500, Daniel Jacobowitz wrote:
> > On Thu, Nov 27, 2003 at 02:53:36PM +1030, Alan Modra wrote:
> > [about size_htab->hash_f being trashed by pch]
> > 
> > What should happen in your case is the
> > PCH file being rejected because the layout of global variables has
> > changed.
> 
> I don't think the layout of global vars changed with the patches I made,
> just code in .text.  A simple test that _etext and _end were unchanged
> would catch most cases..

This way lies madness (and we're already some distance down this path).

We already have a simple check for this in c-pch.c.  If anything more
complex is desired, I would suggest one of two things:

a) the Linux kernel uses a 'build number' to distinguish cases like
  these.  The first time you type 'make', you get a kernel with
  version number like '2.4.20 #1'; if you do 'make' again in the same
  directory, even with nothing changed, it rebuilds and relinks and
  you get '2.4.20 #2'.

b) compute a proper checksum (maybe using MD5) of every file that goes
  into the link of cc1, except of course the file containing the
  checksum, and use that for the 'same executable' part of the PCH
  verification.

There is an option (c), if you're willing to do much more work, but
you'll want (b) first anyway.

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


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