>>
> I do build with the no-asm option, and I'm seeing the problem.
>
> I'm suspicious that somehow the compiler optimization is generating code
> that doesn't work quite right on the UltraSPARC 2e.
I have seen this a few times now so I also felt, hrmmm, something not
quite right happening on these old slow netra boxes. Which, by the way,
make great indestructible DNS servers.
In any case I changed the CFLAGS for the solaris64-sparcv9-cc option in
Configure thus :
"solaris64-sparcv9-cc","cc:
-m64 -xtarget=ultra2e -xarch=sparcvis -xchip=ultra2e -xcache=generic
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
-xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee
-mc -g -xs -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf
-xunroll=1 -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS
-D_LARGEFILE64_SOURCE -D_REENTRANT -xdepend -DB_ENDIAN
::-D_REENTRANT:ULTRASPARC:-lsocket -lnsl -ldl:
BN_LLONG RC4_CHAR RC4_CHUNK DES_INT DES_PTR DES_RISC1 DES_UNROLL
BF_PTR:${sparcv9_asm}:dlfcn:solaris-shared:
-KPIC:-m64 -G -dy -z text:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::/64",
So the objective was to correct the wrong -xarch flag that has been in
there for ages and also to get a full debug version which would be easy
to single step through.
So that works fine.
So what I will look for is where the time calc is done, single step
through that and find out why we get a 0.00sec time.
Dennis
