On Fri, Nov 01, 2002 at 12:03:47AM +0000, Nix wrote:
> On Wed, 30 Oct 2002, Jan Harkes moaned:
> > 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 C++ ABI requires that such things will happen for non-POD types, but
> not for POD types; so avoid virtual functions, constructors,
> destructors, and private and protected data and you should be fine.

Ahhh, that is useful to know. Is this part of the standard in such a way
that we can rely on this until the C++ standard is revised?

I guess this means that any object stored in RVM (fsobj/volrep/repvol)
should just have public data and methods. How about inheritance? We have
a base class 'volent' that contains common functionality of both
replicated volumes and the underlying volume replica's.

I'm not sure whether I can really get away without any constructors or
overloaded allocators. If we really have to lose those it is probably
better to only access RVM objects through a well defined layer written
in C.

> > 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.
> 
> That's definitely a bug. If you stick a report into GNATS I'll try to
> fix it (probably for 3.3, as 3.2.1 is too imminent to fix it there).

Last time I tried was with gcc-3.0, and it looked like something went
wrong in the assembly code that was added by the compiler where we were
returning from a function/method call. I believe it was trying to pop
data off of the stack that was never added in the first place. I was
assuming this was related to exception handling.

This could very well be fixed by now, in fact I just googled and found
this report which very closely matches what I was seeing.

    http://www.geocrawler.com/lists/3/GNU/356/0/9429509/

On the other hand, I'm sure I have not seen any of Coda's source use
__label__, so it could still be a different problem.

btw. I have by now received at least 3 reports of people that have not
observed any unusual problems from their gcc-3.x compiled Coda clients.

Jan