On Mon, Sep 12, 2016 at 5:02 AM, Andrew Marlow <[email protected]> wrote: > Many thanks for releasing version 564. I see there are lots of improvements > :-) >
Yeah, the Solaris folks got a lot of improvements. You guys deserve it for enduring SunCC. SunCC is a good compiler when its not fighting back or not crashing. In the Crypto++ context I find it produces code slightly less than GCC/ICPC, but better than Clang and MSC. > I had a go testing it on Solaris 11 with Sun Studio 12.4 in 64 bit and have > to report a few problems: > > 1) There could be more info in the Readme.txt to explain how to build it on > solaris. OK,for this, I think we need a wiki page. Wiki pages get indexed by search engines, so users will find the information easier. Wiki pages are on my TODO list. I need a 32-hour day.... > 2) I had to hack the makefile to remove use of the -pipe option, near where > it says: Add -pipe for everything except ARM (allow ARM-64 because they > seems to have > 1 GB of memory) OK, so this is going to be tough but doable with tradeoffs. The complete remediation would be to get VM stats in the makefile, but that's not going to happen. When I experienced the problem, I was surprised to learn a dev-workstation with 8GB of AM and 100+ GB of storage did not have enough virtual memory to compile a program. I added more virtual memory to solve the problem; see "Verify there's enough memory and storage to compile a file?", http://superuser.com/q/1098800 . The tradeoff is to disable -pipe for Solaris. It may fix the problem but it will surely slow down compiles. My question to you is: what is it you want us to do? Do you want us to disable -pipe for Solaris? Just SunCC? Maybe something else? > 3) The test program core dumps when run with the v option. > Testing MessageDigest algorithm SHA-384. > ..signal BUS (invalid address alignment) in CryptoPP::SHA512::Transform at > line 27 in file "sha.cpp" > 27 #define blk0(i) (W[i] = data[i]) > (dbx) print data > data = 0xffffffff7fffc1ec > (dbx) print i > dbx: "i" is not defined in the scope > `cryptest.exe`sha.cpp`CryptoPP::SHA512::Transform(unsigned long long*,const > unsigned long long*)` > dbx: see `help scope' for details > (dbx) where > =>[1] CryptoPP::SHA512::Transform(state = 0x1010f1980, data = > 0xffffffff7fffc1ec) (optimized), at 0x1006041a8 (line ~27) in "sha.cpp" > [2] CryptoPP::IteratedHashWithStaticTransform<unsigned long > long,CryptoPP::EnumToType<CryptoPP::ByteOrder,1>,128U,64U,CryptoPP::SHA384,48U,false>::HashEndianCorrectedBlock(this > = 0x1010f18d0, data = 0xffffffff7fffc1ec) (optimized), at 0x1004b30b8 (line > ~89) in "iterhash.h" > [3] CryptoPP::IteratedHashBase<unsigned long > long,CryptoPP::HashTransformation>::HashMultipleBlocks(this = 0x1010f18d0, > input = 0xffffffff7fffc1ec, length = <value unavailable>) (optimized), at > 0x1005cff6c (line ~91) in "iterhash.cpp" OK, this is good stuff here. I can't duplicate in my modest test environment, but its obvious 'data = 0xffffffff7fffc1ec' is only aligned to 2-bytes, while you likely need 8-byte or 16-byte alignment due to SSE2. Here's the first - and only - thing you should do at the moment: gmake distclean cp config.recommend config.h gmake -j 4 ... ./cryptest.exe v ./cryptest.exe tv all That should isolate it to the known undefined behavior we are [currently] carrying around. If it fixes the issue, then problem solved until we can make config.recommend the default (Crypto++ 5.7 when it arrives). The hairier result is, it does not fix the problem. In this case, we will need to investigate why the caller is not using OptimalDataAlignment(). Also see https://www.cryptopp.com/docs/ref/class_s_h_a3.html. Jeff -- -- 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. --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
