1.1.1 pre1 tests failing on Solaris SPARC

classic Classic list List threaded Threaded
60 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Andy Polyakov-2
>> And "the default for all v9 architectures is -xmemalign=8s".
> I'm getting confused.  Since I did not specify -xmemalign at all,

And not specifying -xmemalign is equivalent of specifying 8s in 64-bit
build such as one in question.

> why
> did the test fail with SIGBUS in the first place?  Seems like there
> should have been no alignment problem if the compiler is doing the right
> thing by default as you say.

Once again, objects on stack are *customarily* aligned at pointer size,
i.e. at 8 bytes in -xarch=v9 case, even if their declaration doesn't
imply corresponding guarantee. Or in other words, specifically in
context of this question, even though 'buf' is *not required* to be
aligned at 8 bytes by language standard, so far it was effectively
observed to be aligned anyway, at least on other RISC platforms. Now,
I'm *not* saying that we should *rely* on this custom, rather contrary,
we definitely should *not*. Question is what does the fact that it went
unnoticed till now mean. Or in more practical terms are there more such
dependencies that shouldn't be there? Because if possible, it would only
be appropriate to locate and eliminate them. In yet other words, mystery
is not why this specific test crashed on you, but rather what else can
crash (but doesn't for some reason).
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
In reply to this post by Norm Green
On 21/02/18 04:53 PM, Norm Green wrote:
> On 2/21/2018 12:46 PM, Andy Polyakov wrote:
>> And "the default for all v9 architectures is -xmemalign=8s".
> I'm getting confused.  Since I did not specify -xmemalign at all..

Without getting into some needed CFLAGS let me just say that the build
ran fine here other than test/ct_test.c needs to link with libm. I just
tossed in the required -lm on the EX_LIBS in the Makefile.  Not optimal
but gets the job done for the moment.  Also there is a nagging perl
version problem and that is just .. annoying.

So testsuite is running but this is a non-optimal debug build and only
on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
ELF header below which is somewhat restrictive.

corv $ elfdump -devl ./apps/openssl

ELF Header
   ei_magic:   { 0x7f, E, L, F }
   ei_class:   ELFCLASS64          ei_data:       ELFDATA2MSB
   ei_osabi:   ELFOSABI_SOLARIS    ei_abiversion: EAV_SUNW_CURRENT
   e_machine:  EM_SPARCV9          e_version:     EV_CURRENT
   e_type:     ET_EXEC
   e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
   e_entry:           0x10001c600  e_ehsize:     64  e_shstrndx:  29
   e_shoff:              0xe0ea38  e_shentsize:  64  e_shnum:     31
   e_phoff:                  0x40  e_phentsize:  56  e_phnum:     6

Version Needed Section:  .SUNW_version
      index  file                        version
        [2]  libssl.so                   OPENSSL_1_1_0        [ INFO ]
        [3]                              OPENSSL_1_1_1
        [4]  libcrypto.so                OPENSSL_1_1_0        [ INFO ]
        [5]                              OPENSSL_1_1_1
        [6]  libsocket.so.1              SUNW_0.7
        [7]  libpthread.so.1             SUNW_1.2
        [8]                              SUNW_0.9             [ INFO ]
        [9]  libc.so.1                   SUNW_1.21.2
       [10]                              SUNW_0.7             [ INFO ]

Dynamic Section:  .dynamic
      index  tag                value
        [0]  NEEDED            0x6d18              libssl.so
        [1]  NEEDED            0x6d3e              libcrypto.so
        [2]  NEEDED            0x6d9b              libz.so.1
        [3]  NEEDED            0x6d4b              libsocket.so.1
        [4]  NEEDED            0x6da5              libnsl.so.1
        [5]  NEEDED            0x6db1              libdl.so.1
        [6]  NEEDED            0x6d63              libpthread.so.1
        [7]  NEEDED            0x6d85              libc.so.1
        [8]  INIT              0x1006caa58
        [9]  FINI              0x1006caa68
       [10]  RUNPATH           0x6dbc
/usr/local/lib:/usr/local/ssl/lib
       [11]  RPATH             0x6dbc
/usr/local/lib:/usr/local/ssl/lib
       [12]  HASH              0x1000001d0
       [13]  STRTAB            0x10000c9c0
       [14]  STRSZ             0x6fde
       [15]  SYMTAB            0x1000033d8
       [16]  SYMENT            0x18
       [17]  CHECKSUM          0x33bc
       [18]  VERNEED           0x1000139a0
       [19]  VERNEEDNUM        0x5
       [20]  PLTRELSZ          0x7b60
       [21]  PLTREL            0x7
       [22]  JMPREL            0x100014a90
       [23]  RELA              0x100014700
       [24]  RELASZ            0x7ef0
       [25]  RELAENT           0x18
       [26]  DEBUG             0
       [27]  SUNW_CAP          0x1000001b0
       [28]  FLAGS             0                   0
       [29]  FLAGS_1           0                   0
       [30]  SUNW_STRPAD       0x200
       [31]  SUNW_LDMACH       0x2b                EM_SPARCV9
       [32]  PLTGOT            0x1007ead00
    [33-43]  NULL              0

corv $ LD_LIBRARY_PATH=`pwd` ./apps/openssl version
OpenSSL 1.1.1-pre1 (alpha) 13 Feb 2018
corv $

So .. this is progress.

Dennis

ps: Oracle bugid 26277061 explains e_flags must only be EF_SPARCV9_TSO
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
In reply to this post by OpenSSL - User mailing list

I have run into a bit of a snag here.  Firstly everything compiles just
fine with zero code changes. Zero. All we need are some careful CFLAGS
and the compile moves along swimmingly. However the test stage gets
terribly wedged just after test 70-test_clienthello.t completes. Not
sure why but the various scripts and test files are hell bent on using
the perl in the system as opposed to what I have set in an env var
PERL=/usr/local/bin/perl.  That may be the issue. Not sure.  Also would
be really nice if all the shell scripts could use the the bash shell in
the env var CONFIG_SHELL which is pointed to /usr/local/bin/bash.

If you have any thoughts let me know or I will jsut keep on with my awk
and sed kung fu here changing all the scripts.

Dennis


ps: I still need to get this all built for baseline v9 and not the
      more modern processors :


corv $ elfdump -devl ./apps/openssl

ELF Header
   ei_magic:   { 0x7f, E, L, F }
   ei_class:   ELFCLASS64          ei_data:       ELFDATA2MSB
   ei_osabi:   ELFOSABI_SOLARIS    ei_abiversion: EAV_SUNW_CURRENT
   e_machine:  EM_SPARCV9          e_version:     EV_CURRENT
   e_type:     ET_EXEC
   e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
   e_entry:           0x10001c600  e_ehsize:     64  e_shstrndx:  29
   e_shoff:              0xe0ea38  e_shentsize:  64  e_shnum:     31
   e_phoff:                  0x40  e_phentsize:  56  e_phnum:     6

Version Needed Section:  .SUNW_version
      index  file                        version
        [2]  libssl.so                   OPENSSL_1_1_0        [ INFO ]
        [3]                              OPENSSL_1_1_1
        [4]  libcrypto.so                OPENSSL_1_1_0        [ INFO ]
        [5]                              OPENSSL_1_1_1
        [6]  libsocket.so.1              SUNW_0.7
        [7]  libpthread.so.1             SUNW_1.2
        [8]                              SUNW_0.9             [ INFO ]
        [9]  libc.so.1                   SUNW_1.21.2
       [10]                              SUNW_0.7             [ INFO ]

Dynamic Section:  .dynamic
      index  tag                value
        [0]  NEEDED            0x6d18              libssl.so
        [1]  NEEDED            0x6d3e              libcrypto.so
        [2]  NEEDED            0x6d9b              libz.so.1
        [3]  NEEDED            0x6d4b              libsocket.so.1
        [4]  NEEDED            0x6da5              libnsl.so.1
        [5]  NEEDED            0x6db1              libdl.so.1
        [6]  NEEDED            0x6d63              libpthread.so.1
        [7]  NEEDED            0x6d85              libc.so.1
        [8]  INIT              0x1006caa58
        [9]  FINI              0x1006caa68
       [10]  RUNPATH           0x6dbc /usr/local/lib:/usr/local/ssl/lib
       [11]  RPATH             0x6dbc /usr/local/lib:/usr/local/ssl/lib
       [12]  HASH              0x1000001d0
       [13]  STRTAB            0x10000c9c0
       [14]  STRSZ             0x6fde
       [15]  SYMTAB            0x1000033d8
       [16]  SYMENT            0x18
       [17]  CHECKSUM          0x33bc
       [18]  VERNEED           0x1000139a0
       [19]  VERNEEDNUM        0x5
       [20]  PLTRELSZ          0x7b60
       [21]  PLTREL            0x7
       [22]  JMPREL            0x100014a90
       [23]  RELA              0x100014700
       [24]  RELASZ            0x7ef0
       [25]  RELAENT           0x18
       [26]  DEBUG             0
       [27]  SUNW_CAP          0x1000001b0
       [28]  FLAGS             0                   0
       [29]  FLAGS_1           0                   0
       [30]  SUNW_STRPAD       0x200
       [31]  SUNW_LDMACH       0x2b                EM_SPARCV9
       [32]  PLTGOT            0x1007ead00
    [33-43]  NULL              0

corv $ LD_LIBRARY_PATH=`pwd` ./apps/openssl version
OpenSSL 1.1.1-pre1 (alpha) 13 Feb 2018
corv $
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Andy Polyakov-2
In reply to this post by Dennis Clarke-2
> So testsuite is running but this is a non-optimal debug build and only
> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
> ELF header below which is somewhat restrictive.
>
>   e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]

If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and
EF_SPARC_SUN_US3, then it's likely to be between you and
compiler/run-time. The flags are set by linker as logical 'or' of flags
from all input object files involved. What you need is to identify which
of the *.o files that carries additional flags. On Linux I'd simply
'find . -name \*.o -exec file {} \;' and would show things like "Sun
UltraSPARC1 Extensions Required". If you find nothing among OpenSSL .o
files, then flag comes from elsewhere, and that would be question to
vendor. But even if you find OpenSSL *.o file with undesired flag, it
would still be question to vendor, because -xarch=v9 is documented to
mean "no extensions please", so there shouldn't be any.

As for -lm, which symbol was undefined?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Richard Levitte - VMS Whacker-2
In reply to this post by Dennis Clarke-2
In message <[hidden email]> on Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke <[hidden email]> said:


dclarke> Not sure why but the various scripts and test files are hell
dclarke> bent on using the perl in the system as opposed to what I
dclarke> have set in an env var PERL=/usr/local/bin/perl.

Hmmm, if it's hell bent on anything, it's on what perl was used to run
'Configure'.  I'm not sure if you use that script directly or if you
use 'config'...  the latter will certainly look at $PERL to run
'Configure', and this one will register $^X (perl's internal variable
to indicate the exact file name of the interpreter), which is then
propagated to Makefile (make variable $(PERL)) and used there.  Did we
miss a spot?  I'm willing to correct that...

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
In reply to this post by Andy Polyakov-2
On 24/02/18 04:47 AM, Andy Polyakov wrote:
>> So testsuite is running but this is a non-optimal debug build and only
>> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
>> ELF header below which is somewhat restrictive.
>>
>>    e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
>
> If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and
> EF_SPARC_SUN_US3 ...
<snip>

I wasn't clear. I know exactly what causes this. I am saying that I will
have to redo everything again and get the process down to a baseline
config.

> As for -lm, which symbol was undefined?
>

Undefined                       first referenced
  symbol                             in file
fabs                                test/ct_test.o

dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
In reply to this post by Richard Levitte - VMS Whacker-2
On 24/02/18 05:13 AM, Richard Levitte wrote:

> In message <[hidden email]> on Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke <[hidden email]> said:
>
>
> dclarke> Not sure why but the various scripts and test files are hell
> dclarke> bent on using the perl in the system as opposed to what I
> dclarke> have set in an env var PERL=/usr/local/bin/perl.
>
> Hmmm, if it's hell bent on anything, it's on what perl was used to run
> 'Configure'.  I'm not sure if you use that script directly or if you
> use 'config'...  the latter will certainly look at $PERL to run

OKay ... I can try "config" however I did use "Configure" :

corv $ ./Configure shared zlib threads solaris64-sparcv9-cc


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
In reply to this post by Richard Levitte - VMS Whacker-2
On 24/02/18 05:13 AM, Richard Levitte wrote:

> In message <[hidden email]> on Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke <[hidden email]> said:
>
>
> dclarke> Not sure why but the various scripts and test files are hell
> dclarke> bent on using the perl in the system as opposed to what I
> dclarke> have set in an env var PERL=/usr/local/bin/perl.
>
> Hmmm, if it's hell bent on anything, it's on what perl was used to run
> 'Configure'.  I'm not sure if you use that script directly or if you
> use 'config'...

Ah well ... config isn't too helpful with building a 64-bit lib :


corv $
corv $ ./config
Operating system: sun4u-whatever-solaris2
WARNING! If you wish to build 64-bit library, then you have to
          invoke './Configure solaris64-sparcv9-cc' *manually*.
Using implicit seed configuration
Configuring OpenSSL version 1.1.1-pre1 (0x10101001L) for solaris-sparcv9-cc
Creating configdata.pm
Creating Makefile

NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the
disabled
options or the "make variables" with their values.  Instead, you must use
'configdata.pm' as a script to get a display of the configuration data.  For
help, please do this:

         perl configdata.pm --help
corv $


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Andy Polyakov-2
In reply to this post by Dennis Clarke-2
>> As for -lm, which symbol was undefined?
>>
>
> Undefined                       first referenced
>  symbol                             in file
> fabs                                test/ct_test.o

??? One can only wonder where does it come from. I see no fabs anywhere...

There also was remark about shell. Why? We don't aim for any specific
flavour, or in other words it's expected to work with *any*
Bourne-compatible shell, or in yet other words if it doesn't, then we'd
rather hear about it and eliminate the dependency.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
On 24/02/18 07:51 AM, Andy Polyakov wrote:
>>> As for -lm, which symbol was undefined?
>>>
>>
>> Undefined                       first referenced
>>   symbol                             in file
>> fabs                                test/ct_test.o
>
> ??? One can only wonder where does it come from. I see no fabs anywhere...
>


${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -L. -mt  \
         -o test/crltest test/crltest.o \
           test/libtestutil.a -lcrypto -lz -lsocket -lnsl -ldl -lpthread
/opt/developerstudio12.6/bin/cc  -Iinclude -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -DDSO_DLFCN
-DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM -DPOLY1305_ASM -I/usr/local/include
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO  -c -o
test/ct_test.o test/ct_test.c
/usr/openwin/bin/makedepend -f- -o"|test/ct_test.o" --  -Iinclude
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64
-xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc
-ftrap=%none -Qy -xs -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-DDSO_DLFCN -DHAVE_DLFCN_H -DZLIB -DNDEBUG -DOPENSSL_NO_STATIC_ENGINE
-DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE
-D_TS_ERRNO  -c -- test/ct_test.c \
     >test/ct_test.d.tmp 2>/dev/null
/usr/local/bin/perl -i -pe 's/^.*\|//; s/ \/(\\.|[^ ])*//; $_ = undef if
(/: *$/ || /^(#.*| *)$/); $_.="\n" unless !defined($_) or /\R$/g;'
test/ct_test.d.tmp
rm -f test/ct_test
${LDCMD:-/opt/developerstudio12.6/bin/cc} -errfmt=error -erroff=%none
-errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa
-xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xs
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  -L. -mt  \
         -o test/ct_test test/ct_test.o \
           test/libtestutil.a -lcrypto -lz -lsocket -lnsl -ldl -lpthread
Undefined                       first referenced
  symbol                             in file
fabs                                test/ct_test.o
ld: fatal: symbol referencing errors. No output written to test/ct_test
gmake[1]: *** [Makefile:10579: test/ct_test] Error 2
gmake[1]: Leaving directory
'/usr/local/build/openssl-1.1.1-pre1_SunOS5.10_sparcv9.002'
gmake: *** [Makefile:143: all] Error 2
corv $ find . | grep "ct_test"
./test/ct_test.c
./test/ct_test.d
./test/ct_test.o
corv $
corv $ grep "math\.h" ./test/ct_test.c
#include <math.h>
corv $
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Richard Levitte - VMS Whacker-2
In reply to this post by Dennis Clarke-2
In message <[hidden email]> on Sat, 24 Feb 2018 06:14:50 -0500, Dennis Clarke <[hidden email]> said:

dclarke> On 24/02/18 05:13 AM, Richard Levitte wrote:
dclarke> > In message <[hidden email]> on
dclarke> > Sat, 24 Feb 2018 00:24:34 -0500, Dennis Clarke <[hidden email]>
dclarke> > said:
dclarke> > dclarke> Not sure why but the various scripts and test files are hell
dclarke> > dclarke> bent on using the perl in the system as opposed to what I
dclarke> > dclarke> have set in an env var PERL=/usr/local/bin/perl.
dclarke> > Hmmm, if it's hell bent on anything, it's on what perl was used to run
dclarke> > 'Configure'.  I'm not sure if you use that script directly or if you
dclarke> > use 'config'...  the latter will certainly look at $PERL to run
dclarke>
dclarke> OKay ... I can try "config" however I did use "Configure" :
dclarke>
dclarke> corv $ ./Configure shared zlib threads solaris64-sparcv9-cc

Ah, yes.  And since you probably have the system perl first along your
$PATH, that's the one you're gonna get registered.  The workaround
would be this:

/usr/local/bin/perl ./Configure shared zlib threads solaris64-sparcv9-cc

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Richard Levitte - VMS Whacker-2
In reply to this post by Andy Polyakov-2
In message <[hidden email]> on Sat, 24 Feb 2018 13:51:45 +0100, Andy Polyakov <[hidden email]> said:

appro> >> As for -lm, which symbol was undefined?
appro> >>
appro> >
appro> > Undefined                       first referenced
appro> >  symbol                             in file
appro> > fabs                                test/ct_test.o
appro>
appro> ??? One can only wonder where does it come from. I see no fabs anywhere...

Errrr....

    : ; git grep fabs
    test/ct_test.c:    if (!TEST_uint_le((unsigned int)fabs(difftime(time(NULL), default_time)),

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Andy Polyakov-2
In reply to this post by Dennis Clarke-2
>>>> As for -lm, which symbol was undefined?
>>>>
>>>
>>> Undefined                       first referenced
>>>   symbol                             in file
>>> fabs                                test/ct_test.o
>>
>> ??? One can only wonder where does it come from. I see no fabs
>> anywhere...

Ah! Missed it! There is fabs call in ct_test. I was looking for
reference in binary code. On multiple platforms including Solaris x86.
Question is how come it isn't a problem anywhere else. It looks like
it's customarily inlined, but not here. Well, you insist on
-xbuiltin=%none, so I suppose this has to be it. In such case it's on you...
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Andy Polyakov-2
>>>>> As for -lm, which symbol was undefined?
>>>>>
>>>>
>>>> Undefined                       first referenced
>>>>   symbol                             in file
>>>> fabs                                test/ct_test.o
>>>
>>> ??? One can only wonder where does it come from. I see no fabs
>>> anywhere...
>
> Ah! Missed it! There is fabs call in ct_test. I was looking for
> reference in binary code. On multiple platforms including Solaris x86.
> Question is how come it isn't a problem anywhere else. It looks like
> it's customarily inlined, but not here. Well, you insist on
> -xbuiltin=%none, so I suppose this has to be it. In such case it's on you...

Well, one can probably argue that it might be appropriate to solve it
anyway. And provided that this is the *only* reference to -lm, it
wouldn't be inappropriate to solve it rather by casting difftime return
value to integer and then passing it to abs(3).
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Erik Forsberg-11
In reply to this post by Dennis Clarke-2
as that is the ONLY -lm reference and the fact its in test code, why not
simply avoid using fabs(), that is so trivial here ?

if (value < 0)
    value = -value;


>-- Original Message --
>
>On 24/02/18 04:47 AM, Andy Polyakov wrote:
>>> So testsuite is running but this is a non-optimal debug build and only
>>> on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the
>>> ELF header below which is somewhat restrictive.
>>>
>>>    e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
>>
>> If "somewhat restrictive" refers to presence of EF_SPARC_SUN_US1 and
>> EF_SPARC_SUN_US3 ...
><snip>
>
>I wasn't clear. I know exactly what causes this. I am saying that I will
>have to redo everything again and get the process down to a baseline
>config.
>
>> As for -lm, which symbol was undefined?
>>
>
>Undefined                       first referenced
>  symbol                             in file
>fabs                                test/ct_test.o
>
>dc
>--
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Erik Forsberg-11
In reply to this post by Andy Polyakov-2

>-- Original Message --
>
>>> As for -lm, which symbol was undefined?
>>>
>>
>> Undefined                       first referenced
>>  symbol                             in file
>> fabs                                test/ct_test.o
>
>??? One can only wonder where does it come from. I see no fabs anywhere...
>

/*
 * Tests that the CT_POLICY_EVAL_CTX default time is approximately now.
 * Allow +-10 minutes, as it may compensate for clock skew.
 */
static int test_default_ct_policy_eval_ctx_time_is_now()
{
    int success = 0;
    CT_POLICY_EVAL_CTX *ct_policy_ctx = CT_POLICY_EVAL_CTX_new();
    const time_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) /
            1000;
    const time_t time_tolerance = 600;  /* 10 minutes */

    if (fabs(difftime(time(NULL), default_time)) > time_tolerance) {
        fprintf(stderr,
                "Default CT_POLICY_EVAL_CTX time is not approximately now.\n");
        goto end;
    }
    if (fabs(difftime(time(NULL), default_time)) > time_tolerance) {
        fprintf(stderr,
                "Default CT_POLICY_EVAL_CTX time is not approximately now.\n");
        goto end;
    }

    success = 1;
end:
    CT_POLICY_EVAL_CTX_free(ct_policy_ctx);
    return success;
}



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Erik Forsberg-11
In reply to this post by Andy Polyakov-2

>-- Original Message --
>
>>>>> As for -lm, which symbol was undefined?
>>>>>
>>>>
>>>> Undefined                       first referenced
>>>>   symbol                             in file
>>>> fabs                                test/ct_test.o
>>>
>>> ??? One can only wonder where does it come from. I see no fabs
>>> anywhere...
>
>Ah! Missed it! There is fabs call in ct_test. I was looking for
>reference in binary code. On multiple platforms including Solaris x86.
>Question is how come it isn't a problem anywhere else. It looks like
>it's customarily inlined, but not here. Well, you insist on
>-xbuiltin=%none, so I suppose this has to be it. In such case it's on you...

Most compilers (including gcc) inlines fabs()
Solaris cc does not when using -O0 -g which I use when debugging.
If I remember correctly, solaris cc also inlines when using higher level of optimization
but I may remember wrong.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

Dennis Clarke-2
On 24/02/18 02:18 PM, Erik Forsberg wrote:

>
>> -- Original Message --
>>
>>>>>> As for -lm, which symbol was undefined?
>>>>>>
>>>>>
>>>>> Undefined                       first referenced
>>>>>    symbol                             in file
>>>>> fabs                                test/ct_test.o
>>>>
>>>> ??? One can only wonder where does it come from. I see no fabs
>>>> anywhere...
>>
>> Ah! Missed it! There is fabs call in ct_test. I was looking for
>> reference in binary code. On multiple platforms including Solaris x86.
>> Question is how come it isn't a problem anywhere else. It looks like
>> it's customarily inlined, but not here. Well, you insist on
>> -xbuiltin=%none, so I suppose this has to be it. In such case it's on you...
>
> Most compilers (including gcc) inlines fabs()
> Solaris cc does not when using -O0 -g which I use when debugging.
> If I remember correctly, solaris cc also inlines when using higher level of optimization
> but I may remember wrong.
>

I like having nice debug builds first that I can single step through if
needed.  The joy of fast processors and buckets of cheap memory is that
I can have an entire dev type amp stack that runs just fine with debug
libs everywhere and then a prod stack which is slightly more optimal.

In any case, this seems to me like we are fetching a unit64_t type of
number for milliseconds and should just check if it is within 600000
of some value for "now".  No need for the divide by 1000 in there.

Looking in ./include/openssl/ct.h  we see :

/*
  * Gets the time, in milliseconds since the Unix epoch, that will be
used as the
  * current time when checking whether an SCT was issued in the future.
  * Such SCTs will fail validation, as required by RFC6962.
  */
uint64_t CT_POLICY_EVAL_CTX_get_time(const CT_POLICY_EVAL_CTX *ctx);


OKay so it is an uint64_t for milliseconds.  Perfect.  So maybe just use
that in line 503 :



uint64_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx);


What in the name of Smokey Robinson is TEST_uint_le?  Looks to be a
  "define" in ./test/testutil.h :

# define TEST_uint_le(a, b)   test_uint_le(__FILE__, __LINE__, #a, #b, a, b)

uh huh ...  and in turn where is test_uint_le coming from ?

I don't know.  No where in the tarball that is for sure.

I do see it out in the world at :

https://github.com/openssl/openssl/blob/master/test/test_test.c

Seems like a test for "less than or equal to" for two uintXX_t things.

Regardless there isn't a need for a double difftime nor a floating point
  fabs here.  Am I missing something obvious ?


dc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 1.1.1 pre1 tests failing on Solaris SPARC

FooCrypt
In reply to this post by Dennis Clarke-2
Morning Dennis, et al


This may be off thread topic, but one thing I have noticed with the x86
openssl builds shipped by Oracle and Blastwave in the releases I have
been testing FooCrypt against ( 10u11 through 11.3 ) is that openssl
seems to ‘HANG’ when inputting a string greater than 262 characters
which is quite different behavious to the Linux / macOS stock builds
that accept a string of up to 522 characters.

Anyone know if this is a ‘feature’ of the Solaris x86 compiles or is it
inherent to openssl compiling on Solaris x86 ?

name -a : SunOS FooCrypt 5.10 Generic_147148-26 i86pc i386 i86pc

/opt/csw/bin/openssl version OpenSSL 1.0.2n  7 Dec 2017


name -a : SunOS FooCrypt 5.11 11.3 i86pc i386 i86pc

/opt/csw/bin/openssl version : OpenSSL 1.0.2n  7 Dec 2017

/usr/bin/openssl version : OpenSSL 1.0.1p 9 Jul 2015





Regards,

Mark A. Lane

Cryptopocalypse NOW 01 04 2016

Volumes 0.0 NOW available through iTunes - iBooks @
https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11

Cryptopocalypse NOW is the TRUE story behind the trials and tribulations
encountered in creating "FooCrypt, A Tale of Cynical Cyclical
Encryption." due to the Australian Government's ( led by Malcolm
Turnbull ) criminalisation of encryption technologies on the 1st of
April, 2016, as told by a Convicted Hacker.

"FooCrypt, A Tale of Cynical Cyclical Encryption." is aimed at hardening
several commonly used Symmetric Open Source Encryption methods so that
they are hardened to a standard that is commonly termed 'QUANTUM
ENCRYPTION'.

"FooCrypt, A Tale of Cynical Cyclical Encryption." is currently under
export control by the Australian Department of Defence Defence Export
Controls Office due to the listing of Cryptology as a ‘Dual Use’
Technology as per the ‘Wassenaar Arrangement’

Limited Edition Collectors versions and Hard Back Editions are available
via the store on http://www.foocrypt.net/

© Mark A. Lane 1980 - 2018, All Rights Reserved.
© FooCrypt 1980 - 2018, All Rights Reserved.
© FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2018, All
Rights Reserved.
© Cryptopocalypse 1980 - 2018, All Rights Reserved.


On 2018-02-21 11:42, Dennis Clarke wrote:

> On 21/02/18 12:11 PM, Norm Green wrote:
>> On 2/21/2018 8:42 AM, Dennis Clarke wrote:
>>> Pretty sure I have done builds and tests. In fact I am certain of it.
>>
>> If you added -xmemalign=8s to the SPARC compiler flags (as shown in
>> one
>> of your emails from yesterday) then you would not see the problem.
>> -xmemalign=8s forces the compiler to use 8-byte alignment.
>
> Which is correct way to do this on sparc systems.  I am digging into
> the
> whole build process to see what needs to be "hacked" at to get solid
> and
> reasonable results. The real issue is compilers.  Sorry but gcc just
> won't do the right things on sparc and that isn't anyones fault.
>
> This is where we could go down a deep dark hole.  For the sake of
> getting it out there we may as well just admit that the compilers that
> are generally installed on Solaris systems were of the Forte flavour
> way
> back when little dinosaurs were still roaming the datacenters and the
> cost of the license was about $3000 or so. The acquisitions and rename
> of everything happened for a while there and I am surprised no one at
> Sun lost their little minds and called it the Java Enterprise C
> Compiler
> because everything else had "Java" slapped on it. Regardless, the Forte
> name went away and we then had "Sun Studio" which revved up until we
> were able to compile the whole source code base with it and Solaris
> "UNIX" was self hosted and self boot-strappable and time marched on. So
> here we are today with Oracle Studio compilers and they are very very
> good. At least on sparc they are. The concept of doing a compile for a
> very specific machine class was dropped on the market way back in 1999
> or so and I think by 2002 we could target flavours of sparc v9 with the
> vis instructions as well as a lot of hullabaloo about fused multiply
> etc.  However that was a sun4c and sun4m issue back when we needed the
> optional weitek coprocessor.
>
> So anyways the "target" option was born out of necessity to get the
> right opcodes for given sparc units. People had fights over the entire
> x86 platform and Sun dropped it. Then picked it up again.  Then built a
> version for Itanium. Put that on a shelf and hid it. Buried it. Then
> went back and released a general x86 version again. Madness. I had a
> sit
> down coffee with the global manager for the "solaris" product and it is
> history now but the compiler tools for x86 were never the same quality
> as the sparc tools.  Never have been.  One needs to use "fpversion" to
> get the correct target and cache line options but someone at Oracle has
> spilled a coffee and shuffled papers and forgot to release fpversion in
> the latest flavour of the Studio compilers. I will take a look on a big
> new shiney M-class machine and see what is there but I can tell you
> that
> the openssl binaries I build from sources are at least the same speed
> or
> better than the ones shipped out by Oracle. For a given specific type
> of
> machine and sparc target.
>
>
> jupiter # /opt/developerstudio12.5/bin/fpversion
>  A SPARC-based CPU is available.
>  Kernel says main memory's clock rate is 1272.0 MHz.
>
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
>
>  Use "-xtarget=sparc64viiplus -xcache=64/64/2:11264/256/11"
> code-generation option.
>
>  Hostid = 0xBADCAFFE.
>
>
> A much older system may say :
>
>
> mimas $ /opt/solarisstudio12.4/bin/fpversion
>  A SPARC-based CPU is available.
>  Kernel says CPU's clock rate is 500.0 MHz.
>  Kernel says main memory's clock rate is 100.0 MHz.
>
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
>
>  Use "-xtarget=ultra2e -xcache=16/32/1:256/64/1" code-generation
> option.
>
>  Hostid = 0xBADCAFFE.
>
>
> Even more bizarre and older :
>
> ns1_$ /opt/solarisstudio12.4/bin/fpversion
>  A SPARC-based CPU is available.
>  Kernel says CPU's clock rate is 360.0 MHz.
>  Kernel says main memory's clock rate is 90.0 MHz.
>
>  Sun-4 floating-point controller version 0 found.
>  An UltraSPARC chip is available.
>
>  Use "-xtarget=ultra2i -xcache=16/32/1:1024/64/1" code-generation
> option.
>
>  Hostid = 0xDEADBEEF.
>
>
> I say "bizarre" because that is a system that uses the memory options
> which were shipped on the E10k servers and those cache lines are wrong.
> That machine will always report "infinite" performance from openssl
> speed results and be damned if I can figure out why.  Yet.
>
> ns1_$ /usr/local/ssl/bin/openssl speed rsa4096
> Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in
> 0.00s
> Doing 4096 bit public rsa's for 10s: 1436 4096 bit public RSA's in
> 0.00s
> OpenSSL 1.0.2n  7 Dec 2017
> built on: reproducible build, date unspecified
> options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial)
> idea(int) blowfish(ptr)
> compiler: /opt/solarisstudio12.4/bin/c99 -I. -I.. -I../include  -KPIC
> -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -Xc -g -errfmt=error -erroff=%none -xmemalign=8s
> -errshort=full -xstrconst -xildoff -m64 -xnolibmil -xcode=pic32
> -xregs=no%appl -xlibmieee -ftrap=%none -xarch=sparc -mc -xs
> -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
> -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DB_ENDIAN
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
>                   sign    verify    sign/s verify/s
> rsa 4096 bits 0.000000s 0.000000s      inf      inf
>
>
> However the latest from Oracle claims :
>
> $ ls /opt/developerstudio12.6/bin/fpversion
> /opt/developerstudio12.6/bin/fpversion: No such file or directory
>
> However it is in the manual still.
>
> Messy.  Very.
>
> So as I said earlier ... this should be fun.
>
> Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

1.1.1 pre3 on ppc64 with linux 4.15.12 and glibc 2.27-2 --> All tests successful.

Dennis Clarke-2
In reply to this post by OpenSSL - User mailing list
On 20/02/18 02:09 PM, Salz, Rich via openssl-users wrote:
> I agree, let's just use malloc for the reasons you said.  PR later today.

Slightly unrelated .. however :

.
.
.
All tests successful.
Files=146, Tests=1341, 337 wallclock secs ( 3.35 usr  0.57 sys + 297.20
cusr 58.24 csys = 359.36 CPU)
Result: PASS
gmake[1]: Leaving directory
'/usr/local/build/openssl-1.1.1-pre3_4.15.12-genunix_powerpc64.002'
nix ppc64$
nix ppc64$ ldd --version
ldd (Debian GLIBC 2.27-2) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
nix ppc64$
nix ppc64$ uname -r
4.15.12-genunix
nix ppc64$


While sparc is still a bit of a mess I am chaseing down the corner
  issues.


Dennis Clarke
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
123