> I saw your message on the Cryptopp which you attempted to compile with > Sun Studio 11 on Solaris 8. I followed the link and try to download > the zip file, but the file is not there. Could you kindly show me > where can I find the file. I want to try it out.
I eventually heard back from Sun with a suggested workaround, but never got around to testing it until you reminded me. I've now created a working patch against the 5.4 release. You can obtain both the release and the patch from http://www.cryptopp.com/. Here is the note Sun sent me. I was told it hasn't been published on the web yet. ----- Original Message ----- From: "Steve Clamage" To: "Wei Dai" Sent: Thursday, March 01, 2007 3:53 PM Subject: Re: (Incident Review ID: 869427) code generation bug when casting to a virtual base class > The problem turned out to be a known bug in the Sun C++ ABI. Here are > the details: > > For some complicated class hierarchies that have empty virtual base > classes, the compiler generates incorrect vtables. If we fix this > compiler bug, code generated by the fixed compiler would not be > compatible with code generated by unfixed compilers. Mixing binary > code from different compiler releases or patch levels could result in > a program that didn't run, even if the program ran correctly using > the unfixed compiler exclusively. > > The symptoms of this bug are bizarre behavior when calling a virtual > function, using dynamic_cast, or accessing RTTI data. "Bizarre" > behavior includes calling the wrong function, getting the wrong > type, or getting a program crash. > > In all cases when this bug is encountered, a safe and effective > workaround is to add a dummy data member to each empty virtual base > class in the affected hierarchy. By "empty" virtual base class, I > mean one that has no data members. > > Example: > class VB { // used as a virtual base class > public: > // no data members > virtual void foo() = 0; > virtual ~VB() { } > }; > If you add a dummy data member, such as > char dummy; > > the class is no longer empty, and does not trigger the vtable layout > bug. You do not need to initialize or copy the data member in > constructors or copy operations. You might want to initialize the > data member to 0 to avoid debugger complaints about uninitialized > data, however. > > If you change the definition of a class, you must of course > recompile all the code that uses the class. Ordinarily, using > "make" with proper makefiles takes care of the necessary recompiles > for you. If third-party libraries are involved, you might have a > bigger problem. > > To locate empty virtual base classes, CC has an undocumented > Qoption: > -Qoption ccfe -xwarn_empty_vbase > > Each time a class definition is processed, the compiler will emit a > warning if the class has an empty virtual base class. Code > generation is not affected. > Example warning: > Warning: Class "VB" appears as an empty virtual base class. > > If you cannot modify the class definition for some reason, an > undocumented Qoption is also available: > -Qoption ccfe -xno_empty_vbase > > This Qoption causes the compiler to treat all virtual base classes > as non-empty, affecting the layout of classes and vtables, and > avoiding the compiler bug. > > This Qoption is somewhat dangerous because it results in different > representations for classes without touching source code. It can > also change the layout of classes that were previously correct. > That is, not all hierarchies with empty virtual base classes have > invalid vtables. This Qoption can nevertheless change their layout. > > When using this Qoption, you should recompile ALL code that goes > into the entire program, including libraries that use any of the > classes that are affected. > > System libraries > > One ray of sunshine: None of the libraries supplied with the > compiler are affected by the -xno_empty_vbase option. You therefore > do not need special versions of system libraries. You need only > recompile your own code, and possibly third-party code. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
