On Friday, April 21, 2017 at 11:10:47 PM UTC-4, Jeffrey Walton wrote: > > > On Friday, April 21, 2017 at 10:46:47 PM UTC-4, Anton Gorev wrote: >> >> Other strange thing:... >> ... >> DH validation suite running... >> >> stopped in CryptoPP::BufferedTransformation::GetMaxWaitObjectCount at >> line 398 in file "cryptlib.cpp" >> 398 const BufferedTransformation *t = >> AttachedTransformation();^M >> (dbx) step >> stopped in CryptoPP::Filter::Flush at line 80 in file "filters.cpp" >> 80 switch (m_continueAt)^M >> (dbx) where >> =>[1] CryptoPP::Filter::Flush(this = 0x100f14a68, hardFlush = true, >> propagation = 0, blocking = true), line 80 in "filters.cpp" >> [2] CryptoPP::BufferedTransformation::GetMaxWaitObjectCount(this = >> 0x100f14a68), line 398 in "cryptlib.cpp" >> [3] CryptoPP::BufferedTransformation::ChannelPutModifiable(this = >> 0x100f14a68, channel = CLASS, inString = 0x101168490 "^B\x81\x81", length = >> 256U, blocking = true), line 1866 in "cryptlib.h" >> ... >> >> Why I came into `CryptoPP::Filter::Flush` from `const >> BufferedTransformation *t = AttachedTransformation();`? And why `t` >> eventually has value `0x01`? It is nor `NULL` nor some unaligned address. >> It more seems like some corruption. But I am not sure if it is a >> consequence of using misaligned addresses. >> > > Yeah, that one is unusual. Its probably another function, but DBX is > reporting the wrong one. > > Have you tried turning knobs with your compiler settings? I'm not > convinced Cmake provides good settings out of the box. > > -xmemalign looks like it may have some effect given the workarounds; see > https://docs.oracle.com/cd/E19205-01/819-5265/bjavc/index.html. Be sure > Cmake is not adjusting it to something that's not compatible. > > There's also a note in one of the old GCC manuals about using 8-byte > alignment for SPARC; see > https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Type-Attributes.html. However, > its not present in the current manual. >
By the way, here are the flags Crypto++ uses out of the box before we started changing things at Crypto++ 5.6.3. I consider it the gold standard, and use it as a reference point. But this on an Intel based Proliant DL380 G5, and not a SPARC machine. $ git checkout CRYPTOPP_5_6_2 HEAD is now at 789f81f... prepare for 5.6.2 release $ CXX=/opt/solstudio12.2/bin/CC gmake /opt/solstudio12.2/bin/CC -DNDEBUG -O -g0 -native -template=no%extdef -m64 -c shark.cpp /opt/solstudio12.2/bin/CC -DNDEBUG -O -g0 -native -template=no%extdef -m64 -c zinflate.cpp /opt/solstudio12.2/bin/CC -DNDEBUG -O -g0 -native -template=no%extdef -m64 -c gf2n.cpp ... You can duplicate the compile above on Master once you get the "gold standard" options. The next step would be: $ git checkout master -f Previous HEAD position was 789f81f... prepare for 5.6.2 release Switched to branch 'master' Your branch is up-to-date with 'origin/master'. $ CXX=/opt/solstudio12.2/bin/CC gmake CXXFLAGS="-DNDEBUG -O -g0 -native -template=no%extdef -m64" /opt/solstudio12.2/bin/CC -DNDEBUG -O -g0 -native -template=no%extdef -m64 -c cryptlib.cpp /opt/solstudio12.2/bin/CC -DNDEBUG -O -g0 -native -template=no%extdef -m64 -c cpu.cpp /opt/solstudio12.2/bin/CC -DNDEBUG -O -g0 -native -template=no%extdef -m64 -c integer.cpp I'm wagering Cmake is missing a few of the flags, like "-template=no%extdef" and "-m64". Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
