(Illustration by Gaich Muramatsu)
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. JanReceived on 2002-10-30 13:25:12