On 23 December 2010 18:55, Andrew Haley wrote: > On 12/23/2010 03:37 PM, ronny meeus wrote: > >> we are changing our compiler from gcc version 2.95.3 to a more recent >> version (gcc version 3.4.6). > > Are you sure about this? This is 2010, nearly 2011. You are changing > to a 2004 compiler, last updated in 2006. I completely agree with Andrew, if you have to update to a newer compiler you might as well update to a modern version, or you'll just have to rewrite code again one day. >> What we have observed is that the memory layout of C++ objects with >> virtual functions has been changed. > > This is all to do with the multi-vendor C++ ABI. We had to change gcc > in order to conform to this. > >> Now that we are moving to a newer version, our SW is broken since the >> virtual table ptr is stored as first entry in the object's memory. >> As soon as we insert an object in a list, we simply corrupt the VTABLE >> pointer and the SW soon crashes. >> >> Now my questions are: >> - is there a kind of mode / compiler option to make the new compiler >> use the old memory layout? > > I don't think so. > >> - does somebody know a solution (except rewriting the complete code base) >> ? > > It doesn't sound so terribly hard to fix your macros in order to make > this correct code. > > In addition to the layout problem you're having, (void**)&aptr isn't > even well-defined C++ and may generate incorect code on recent > compilers. So, I think you're going to have to clean this up anyway, > I'm afraid. The code was always non-portable, unsafe and incorrect. Someone really should have noticed it was a problem at some point in the past decade. Why not just assign to list->next? You could still do that with a macro if you have some (probably questionable) reason to avoid templates.
