Coda File System

Re: gcc-3.2

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 30 Oct 2002 13:23:48 -0500
On Wed, Oct 30, 2002 at 10:28:52AM +0100, Marcel Pol wrote:
> I started using codafs very recently, and I noticed it only builds with
> gcc-2.9x.

Correct.

> My question is if the next version of coda can be built with gcc-3.2. If not,

The problem is that gcc-3.x breaks a lot of assumptions that used to be
valid. Class object that used to have an identical layout are no longer
interchangeable, f.i. the doubly linked list headers as stored in
persistent memory (rec_dlist), and normal doubly linked list headers
(dlist). They have identical members and operations, but the recoverable
version marks all pointer modifications as a transaction.

Similarily, allocation of persistent objects, it used to be the case
that the range [&foo, &foo+sizeof(foo)] would contain all information
associated with a C++ object. However the newer gcc's store miscelaneous
data outside of that range, often even allocated off the heap so that
when venus is restarted some of the required information is lost, with
gcc-2.95 this already happens to f.i. any objects with virtual
functions.

The exception handling code conflicts with the userspace thread package.
So we have to compile with -fno-exceptions, but this is obviously not
tested well as gcc-3.x still seems to insist on adding exception
handlers in some places.

I am also suspicious whether gcc-3.x might be overly agressive in
reordering code as it seems like locks are sometimes not properly
taken/released in the right places. Perhaps variables that require
atomicity and should be guarded by locks are still in registers when
the lock is released, or when we yield to another thread.

I've merged patches for 3.x compile errors and warnings, but in general
any 3.x compiled venus invariably has unexplainable lockups, memory
corruptions or startup problems that do not happen when venus is
compiled with g++-2.x. It is one thing to push the code through a 3.x
compiler, but a whole different ballgame to discover why something is
going wrong. Figuring out whether it is a compiler bug, or a problem
with the code, and how to fix it.

Jan
Received on 2002-10-30 13:25:12