131171 - Add HP-UX IPF (ia64) NSS support

Status: RESOLVED FIXED

(NSS :: Build, defect, P1)

Description

[Jim Dunn]

Need to add build configuration for IPF (11.20 on ia64 for hp-UX)

Comment 1

[Jim Dunn]

Attachment: Patch that gets --enable-crypto to work on ipf

I "hacked" the makefiles and such to get this to work.
The unix_rand change is wtc's change from the corresponding
nspr file.  For IPF/hp-ux11.20 we don't have any assembler
so I had to turn off the hybrid freebl build and stick with
the pure32 version.  This is ugly... but am hoping that you
guys will help me clean it up.

machines to try are {asti, verona}
if you look at /u/jdunn/bin/mkmozia64 you will see what I use
as defines and such to get a moz build.  Hollar if you need
anything.

Comment 2

[Wan-Teh Chang]

Comment on attachment 74336 [details] [diff] [review]
Patch that gets --enable-crypto to work on ipf

>+    ifeq ($(OS_TEST), ia64)
>+       OS_CFLAGS       += -Aa +e +p +DD32
>     else

What is the +p compiler option?

Are there any machines at Netscape that we can use?
I tried to compile on asti and corsica but the build
hangs in cc.

Comment 3

[Jim Dunn]

The +p is (i believe) for identifying anachoist (sp) code
(i.e. code that the compiler in newer releases might BALK at)
It isn't a necessity, but we use it for the rest of mozilla
to flag code that we will eventually have to make right as
the compiler becomes more and more c++ strict.

The cc hang is due to a "bad" version of gmake.
You should be using the one in /opt/make/bin (not /tools/ns/bin)
Eventually the machine will be upgraded so that most of the
tools will be in /usr/local - we are working on that!

Comment 4

[Jim Dunn]

correction, use /usr/local/bin/gmake !
I just updated the tool on asti,verona & corsica

Comment 5

[Wan-Teh Chang]

Set target milestone to NSS 3.5.

Comment 6

[Wan-Teh Chang]

Attachment: New file mozilla/security/coreconf/HP-UXB.11.20.mk

Comment 7

[Wan-Teh Chang]

I opened bug 145053 for the PSM changes.

Comment 8

[Wan-Teh Chang]

Attachment: Patch that gets NSS to work on ipf

This patch is derived from Jim Dunn's patch (attachment 74336 [details] [diff] [review]).
It only supports HP-UX ia64 in 32-bit mode.

Comment 9

[Wan-Teh Chang]

Comment on attachment 83955 [details] [diff] [review]
Patch that gets NSS to work on ipf

Nelson,

Could you review this patch, in particular my changes to
lib/freebl/config.mk and lib/freebl/Makefile?  I am not
sure if -DMP_USE_UINT_DIGIT -DMP_NO_MP_WORD is the right
defines to use.

By the way, I think it is a good idea to move ret_cr16.s
to lib/freebl as well.	It is only used by unix_rand.c,
which has been moved to lib/freebl.

Thanks.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Once upon a time, we were directed to move all machine/platform dependent
PRNG code into NSPR.  Since then, NSPR has contained a copy of code used
to initialize the PRNG, but NSS retained its own copy also, and NSS has 
never been switched to use NSPR's versions of these functions.  

I think we ought to either use NSPR's versions of these, or remove them 
from NSPR.  Because of our historical reluctance to use NSPR in PKCS#11
modules, I'd guess we'll end up removing them from NSPR.

Comment 11

[Wan-Teh Chang]

Nelson, that issue is the subject of bug 48258, so I'll follow
up there.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Here are review comments on attachment 83955 [details] [diff] [review].

Re: new GetHighResClock implementation in unix_rand.c,

This code calls _pr_CopyLowBits(), which is appropriate for the version of
unix_rand.c in NSPR, but that function is not defined in NSS's unix_rand.c 
source file.  In NSS's unix_rand.c, you should call CopyLowBits(), which 
is a static function defined elsewhere in that file.  Jim Dunn already made 
that change in the branch he's using.

Re: -DMP_USE_UINT_DIGIT and -DMP_NO_MP_WORD

Those #defines should produce working code on any system with 32-bit
unsigned int type, but they may be suboptimal on a 64-bit system.  

Normally, the ifdef's in mpi.h will attempt to use the largest integer type 
it can find (e.g. long long, or long - if it is larger than int) as its 
"digit", as its basic unit of bignum storage (and hence the size of the 
operands to the arithmetic it performs).  MP_USE_UINT_DIGIT forces mpi.h to 
use unsigned int, and not a larger type, as its "digit".

Even with MP_USE_UINT_DIGIT defined, if a larger type exists, mpi will attempt 
to use it as an accumulator "word" in integer arithmetic.  For example, even
if the unit of storage is 32-bits, mpi will use 64-bit values for arithmetic,
if it can.  MP_NO_MP_WORD tells mpi to use the same type of integer for the 
accumulator "word" as it uses for the "digit".  

On a system with 32-bit uints, these two defines together tell MPI to do
only 32 bit arithmetic and 32-bit storage, no 64-bit arithmetic.  This 
actually produces faster code on some CPUs, notably those that use their 
FPUs to do integer arithmetic and therefore need to ensure that the unit of
storage is smaller than a double's mantissa.  It is also good on systems 
that define larger types than the CPU directly supports, and do the 
arithmetic on those larger types using a software emulation library rather 
than with direct 64-bit instructions.

But on systems with fast 64-bit integer arithmetic, I would suggest not 
defining either of them.  If you find it necessary or desirable to force
MP_USE_UINT_DIGIT, then you should determine whether or not to use 
MP_NO_MP_WORD based on whether the code produced with MP_NO_MP_WORD is 
faster than the code without it.  It is purely a performance tuning feature.

Comment 13

[Wan-Teh Chang]

Attachment: Patch (v2) that gets NSS to work on ipf

This version of the patch incorporates Nelson's suggested changes.
I also added support for 64-bit mode.

Comment 14

[Wan-Teh Chang]

The patch has been checked into the tip of NSS, NSS_3_5_BRANCH,
and the NSS_CLIENT_TAG (which the Mozilla client's trunk is using).

Comment 15

[Wan-Teh Chang]

Jim,

You should merge some of the changes in my patch on the
NETSCAPE_6_2_2_BRANCH and any other branches you are
using.  Your patch creates libfreebl_pure32_3.sl, which
is avoided by my patch.

None of my changes to security/coreconf need to be merged.
I added 64-bit support and arranged the nested if's
differently.  None of these you need for your work.

You should pick up my changes to security/nss/lib/freebl/Makefile,
security/nss/lib/freebl/config.mk, and
security/nss/lib/util/Makefile.  You need to back out
your changes to these files first.

Then, you need to modify your change to
security/manager/Makefile.in (because these is no
libfreebl_pure32_3.sl any more) or simply use my
proposed patch in bug 145053.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

Today, while investigating bug 170379, I determined or verified the following
things about NSS on HPUX B.11.20 for ia64.

1. The performance on ia64 is best when NONE of the optional defines listed 
below is given on the cc command line. 

-DMP_USE_UINT_DIGIT -DMP_NO_MP_WORD -DMP_USE_LONG_LONG_MULTIPLY

Performance with -DMP_USE_UINT_DIGIT was only half of the speed without it.

NSS's libfreebl is now being built on B.11.20 without these options.  So, no 
change to the -D command line options is indicated.  

2. Freebl is being built with -O.  I tested with both -O and +O3 and
found that the -O code took 4.8% longer than the +O3 code to do the same
modular exponentiations.  So, perhaps NSS should consider using +O3.

3. The coreconf makefiles presently define CPU_ARCH=hppa and add -Dhppa to
all cc command lines on HPUX builds, regardless of actual CPU type.  This 
doesn't seem to hurt anything on ia64, but seems wrong.

4. The OBJDIR name doesn't reflect the CPU type.  As long as no single release
of HPUX works with both PARisc and ia64, this should not cause build problems.
But it will not be easy to tell which CPU type is supported from the OBJDIR
name.  And we anticipate that HP will produce a release that works for both 
CPU types, so coreconf should be changed before then to incorporate the CPU
type into the OBJDIR name.