Re: cryptopp-565 core dumps on solaris 11 with sun compiler in unit tests and benchmarks

[Jeffrey Walton]

> I am sorry to report that cryptest.exe v still core dumps on solaris 11 when
> using the sun 12.4 compiler. The command I used to build cryptopp was:
> CXX=/opt/solarisstudio12.4/bin/CC make -j20
>
> The error is:
>
> Testing MessageDigest algorithm SHA-384.
> ..signal BUS (invalid address alignment) in CryptoPP::SHA512::Transform at
> line 34 in file "sha.cpp"
>34   #define blk0(i) (W[i] = data[i])

This is the one we cannot duplicate. Unfortunately, there's nothing we
can do for this one until we can duplicate it.

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.

Re: compilation error from g++ 4.8.2 on solaris when using cryptopp-565

[Jeffrey Walton]

> Since this is fine on RHEL I presume the problem is related to the solaris
> environment. It looks like there the _IP32 macro is not defined. I notice
> that the Sun/Oracle documentation at
> https://docs.oracle.com/cd/E19683-01/806-6543/chapter4-2/index.html says
> that this macro is used to say that the sizes of int, long, and pointer are
> all 32 bits. There is something strange about that macro though. Here is

Also, the Oracle docs don't take Clang into account. Clang will define
ILP32 under all 32-bit data models, and not just ILP32 data model on
x86_64 as the System V ABI spec calls out. That means the preprocessor
macro __ILP32__ bleeds into other platforms, like mipsel, armel and
aarch32. That's why we have to tie x86_64 into the tests.

I asked the LLVM devs about the unusual use of the macro definitions,
and how we should craft the test for Clang users. The LLVM devs are
very arrogant and their response was something like "nothing forbids
it so we do it". Keep in mind everyone else we tested does it
according to the System V spec,  including Comeau, GCC, and ICC. Only
Clang gratuitously defines ILP32.

Here are some related docs and reading:

  * https://sites.google.com/site/x32abi/
  * https://wiki.debian.org/X32Port

For completeness, GCC choking on it is a GCC bug (or an Oracle bug if
Oracle patches introduced it). But as I said earlier, if it breaks the
compile then we'll take it as our bug. We don't want users enduring
it.

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.

cryptopp-565 core dumps on solaris 11 with sun compiler in unit tests and benchmarks

[Andrew Marlow]

Hello,

I am sorry to report that cryptest.exe v still core dumps on solaris 11 
when using the sun 12.4 compiler. The command I used to build cryptopp was: 
CXX=/opt/solarisstudio12.4/bin/CC make -j20

The error is:

Testing MessageDigest algorithm SHA-384.
..signal BUS (invalid address alignment) in CryptoPP::SHA512::Transform at 
line 34 in file "sha.cpp"
   34   #define blk0(i) (W[i] = data[i])

the stack trace is:

(dbx) where
=>[1] CryptoPP::SHA512::Transform(state = , data = 
) (optimized), at 0x1006255a0 (line ~34) in "sha.cpp"
  [2] CryptoPP::IteratedHashWithStaticTransform,128U,64U,CryptoPP::SHA384,48U,false>::HashEndianCorrectedBlock(this
 
= 0x1010c18d0, data = 0x7fffc1b4) (optimized), at 0x1004c8120 (line 
~170) in "iterhash.h"
  [3] CryptoPP::IteratedHashBase::HashMultipleBlocks(this = 0x1010c18d0, 
input = 0x7fffc1b4, length = ) (optimized), at 
0x1005d834c (line ~91) in "iterhash.cpp"
  [4] CryptoPP::IteratedHashBase::Update(this = 0x1010c18d0, input = 
0x7fffc1b4 "aaa [snip]
  [5] CryptoPP::HashVerificationFilter::NextPutMultiple(this = 
0x7fffd550, inString = 0x7fffc15d "aaa [snip]
  [6] CryptoPP::FilterWithBufferedInput::PutMaybeModifiable(this = 
0x7fffd550, inString = 0x7fffc15d 
"a [snip]
  [7] CryptoPP::FilterWithBufferedInput::Put2(this = 0x7fffd550, 
inString = 0x7fffc15d 
"aaa
  [8] CryptoPP::BufferedTransformation::ChannelPut2(this = 
0x7fffd550, channel = CLASS, begin = 0x7fffc15d 
"aaa
  [9] RandomizedTransfer(source = CLASS, target = CLASS, finish = , channel = CLASS) (optimized), at 0x1004e9e94 (line ~92) in 
"datatest.cpp"
  [10] PutDecodedDatumInto(data = CLASS, name = , target 
= CLASS) (optimized), at 0x1004ea41c (line ~138) in "datatest.cpp"
  [11] TestDigestOrMAC(v = CLASS, testDigest = ) 
(optimized), at 0x1004ef674 (line ~603) in "datatest.cpp"
  [12] TestDataFile(filename = CLASS, overrideParameters = CLASS, 
totalTests = 11U, failedTests = 0) (optimized), at 0x1004f0c44 (line ~802) 
in "datatest.cpp"
  [13] RunTestDataFile(filename = 0x100afec60 "TestVectors/sha.txt", 
overrideParameters = CLASS, thorough = true) (optimized), at 0x1004f1168 
(line ~243) in "string"
  [14] ValidateSHA() (optimized), at 0x1004c9228 (line ~212) in 
"validat3.cpp"
  [15] ValidateAll(thorough = false) (optimized), at 0x1004339e8 (line ~95) 
in "validat1.cpp"
  [16] Validate(alg = , thorough = false, seedInput = 
) (optimized), at 0x100380cdc (line ~899) in "test.cpp"
  [17] main(argc = , argv = 0x77d6) 
(optimized), at 0x10037b690 (line ~364) in "test.cpp"

The test program also crashes when the b (benchmark) option is used. 
Interestingly, the crash is in the same place as my own test program 
crashes, in CryptoPP::CountWords, due to a null pointer. Here is the dbx 
output:

signal SEGV (no mapping at the fault 
address) in CryptoPP::CountWords at line 9 in file "words.h"
9   inline size_t CountWords(const word *X, size_t N)
(dbx) print X
X = (nil)
=>[1] CryptoPP::CountWords(X = (nil), N = 144U) (optimized), at 0x1005a4238 
(line ~9) in "words.h"
  [2] CryptoPP::Integer::WordCount(this = 0x1010bfa98) (optimized), at 
0x100596cd8 (line ~3298) in "integer.cpp"
  [3] CryptoPP::Integer::Integer(this = 0x7fffb090, t = CLASS) 
(optimized), at 0x10059573c (line ~2903) in "integer.cpp"
  [4] CryptoPP::RSAFunction::PreimageBound(this = 0x1010bfa80) (optimized), 
at 0x1006c3148 (line ~46) in "rsa.h"
  [5] CryptoPP::AssignFromHelper(pObject = 
0x7fffb000, source = CLASS) (optimized), at 0x1006c35f0 (line ~320) 
in "cryptlib.h"
  [6] CryptoPP::RSAFunction::AssignFrom(this = 0x7fffb000, source = 
CLASS) (optimized), at 0x1006b6854 (line ~93) in "rsa.cpp"
  [7] 
CryptoPP::PK_FinalTemplate,CryptoPP::RSA,int>,CryptoPP::RSA,CryptoPP::OAEP
 
> > >::PK_FinalTemplate(this = 0x7fffafe8, algorithm = CLASS) 
(optimized), at 0x1003a41c8 (line ~2049) in "string"
  [8] 
BenchMarkCrypto
 
> >(filename = , name = 0x1009b27e8 "RSA 1024", 
timeTotal = 1.0, x = ) (optimized), at 0x10041b550 (line 
~248) in "bench2.cpp"
  [9] BenchmarkAll2(t = 1.0, hertz = ) (optimized), at 
0x1003ea460 (line ~288) in "bench2.cpp"
  [10] BenchmarkAll(t = , hertz = ) 
(optimized), at 0x1003e0250 (line ~381) in "bench1.cpp"
  [11] main(argc = , argv = 0x7558) 
(optimized), at 0x10037ade4 (line ~366) in "test.cpp"

Regards,

Andrew Marlow


-- 
-- 
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 

Re: compilation error from g++ 4.8.2 on solaris when using cryptopp-565

[Jeffrey Walton]

On Friday, October 14, 2016 at 5:37:35 AM UTC-4, Andrew Marlow wrote:
>
> Hello everyone,
>
> I am trying out cryptopp-565 to see if it resolves the problems I have 
> been seeing on Solaris 11 using the Sun compiler version 12.4. To this end 
> I have written a standalone program that shows the problem. When I got 
> version 565 I thought I would try building my test program with g++ first. 
> The cryptopp lib itself builds fine and the tests all run and pass. The 
> benchworks also seem ok. And it all works on RHEL 6.8 and my test program 
> works ok there also. But on solaris 11 where I have g++ version 4.8.2 I get 
> a compilation error:
>
> g++ -DNDEBUG -g2 -O2 -fPIC -pipe -c apmtest.cpp
> In file included from apmtest.cpp:6:0:
> config.h:582:34: error: operator '>=' has no left operand
>  #if ((__ILP32__ >= 1) || (_ILP32 >= 1)) && defined(__x86_64__)
>
> Since this is fine on RHEL I presume the problem is related to the solaris 
> environment. It looks like there the _IP32 macro is not defined. I notice 
> that the Sun/Oracle documentation at 
> https://docs.oracle.com/cd/E19683-01/806-6543/chapter4-2/index.html says 
> that this macro is used to say that the sizes of int, long, and pointer 
> are all 32 bits. There is something strange about that macro though. Here 
> is another little program that fails to compile:-
>
> #include 
>
> int main()
> {
> #if defined(_ILP32)
> std::cout << "_ILP32 macro is [" << _ILP32 << "]\n";
> #else
> std::cout << "_ILP32 macro is not defined.\n";
> #endif
> return 0;
> }
>
>
> This fails with:
>
> huh.cpp: In function int main():
> huh.cpp:6:48: error: expected primary-expression before << token
>  std::cout << "_ILP32 macro is [" << _ILP32 << "]\n";
>
> Is anyone else seeing this issue with g++? This program compiles ok on 
> RHEL and outputs that _ILP32 is not defined.
>
> If I change the cryptopp header config.h bit to read:
> #if defined(__x86_64__) && ((__ILP32__ >= 1) || defined(_ILP32))
>
> then the problem goes away. This indicates to me that it is a bug in 
> cryptopp-585 in that one is not supposed to use or test the macro value for 
> _ILP32, only that it is defined.
>

Using __ILP32__ and _ILP32  in an '#if' like above is legal C and C++ The 
preprocessor is supposed to replace it with the value 0 if its not defined. 
Also see http://stackoverflow.com/q/5085392.

Using __ILP32__ and _ILP32 in the C++ program `cout << _ILP32` is not legal 
because __ILP32__ and _ILP32 are not defined. Here, 'not legal' is 
contingent upon a non-X32 system. Effectively __ILP32__ and _ILP32 are 
undeclared identifiers because they escape the preprocessor.

CentOS 5 uses GCC 4.8 but it did not witness the problem. My two Solaris 
11.3 machines with GCC 4.8.2 do not witness it either (see below).

If its breaking a compile then its our bug. We'll get something checked-in 
to address it.

Jeff

--

$ uname -a
SunOS solaris 5.11 11.3 i86pc i386 i86pc

$ g++ --version
g++ (GCC) 4.8.2

$ CXX=g++ gmake
g++ -DNDEBUG -g2 -O2 -fPIC -march=native -m64 -Wa,--divide -pipe -c 
cryptlib.cpp
g++ -DNDEBUG -g2 -O2 -fPIC -march=native -m64 -Wa,--divide -pipe -c cpu.cpp
...

32-bit does not produce the error:

$ CXX=g++ gmake CXXFLAGS="-DNDEBUG -g2 -O2 -fPIC -m32 -pipe"
g++ -DNDEBUG -g2 -O2 -fPIC -m32 -pipe -c cryptlib.cpp
g++ -DNDEBUG -g2 -O2 -fPIC -m32 -pipe -c cpu.cpp
...

I see 32-bit builds have other problems a little further into the make 
process. It looks like the inline assembler is broken, but I'll need to 
investigate it further.

-- 
-- 
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.

compilation error from g++ 4.8.2 on solaris when using cryptopp-565

[Andrew Marlow]

Hello everyone,

I am trying out cryptopp-565 to see if it resolves the problems I have been 
seeing on Solaris 11 using the Sun compiler version 12.4. To this end I 
have written a standalone program that shows the problem. When I got 
version 565 I thought I would try building my test program with g++ first. 
The cryptopp lib itself builds fine and the tests all run and pass. The 
benchworks also seem ok. And it all works on RHEL 6.8 and my test program 
works ok there also. But on solaris 11 where I have g++ version 4.8.2 I get 
a compilation error:

g++ -DNDEBUG -g2 -O2 -fPIC -pipe -c apmtest.cpp
In file included from apmtest.cpp:6:0:
config.h:582:34: error: operator '>=' has no left operand
 #if ((__ILP32__ >= 1) || (_ILP32 >= 1)) && defined(__x86_64__)

Since this is fine on RHEL I presume the problem is related to the solaris 
environment. It looks like there the _IP32 macro is not defined. I notice 
that the Sun/Oracle documentation at 
https://docs.oracle.com/cd/E19683-01/806-6543/chapter4-2/index.html says 
that this macro is used to say that the sizes of int, long, and pointer are 
all 32 bits. There is something strange about that macro though. Here is 
another little program that fails to compile:-

#include 

int main()
{
#if defined(_ILP32)
std::cout << "_ILP32 macro is [" << _ILP32 << "]\n";
#else
std::cout << "_ILP32 macro is not defined.\n";
#endif
return 0;
}


This fails with:

huh.cpp: In function int main():
huh.cpp:6:48: error: expected primary-expression before << token
 std::cout << "_ILP32 macro is [" << _ILP32 << "]\n";

Is anyone else seeing this issue with g++? This program compiles ok on RHEL 
and outputs that _ILP32 is not defined.

If I change the cryptopp header config.h bit to read:
#if defined(__x86_64__) && ((__ILP32__ >= 1) || defined(_ILP32))

then the problem goes away. This indicates to me that it is a bug in 
cryptopp-585 in that one is not supposed to use or test the macro value for 
_ILP32, only that it is defined.

Regards,

Andrew Marlow








-- 
-- 
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.