On 05/13/2014 07:20 PM, Robert Relyea wrote:
On 05/13/2014 03:42 AM, Vicente Olivert Riera wrote:
Hi Paul,
I think I have fixed the problem.
The failure comes from this file
"mozilla/security/nss/lib/freebl/drbg.c" on the line #512, which has
an assert of the size of "size_t":
PR_STATIC_ASSERT(sizeof(size_t) > 4)
That line is inside an #if/#endif block which has this form:
#if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) &&
!defined(NS_PTR_LE_32))
So, that code is being executed because "NSS_USE_64" is true.
The problem is that in MIPS64 n32 the size of size_t is exactly 4 (is
an unsigned integer of 32 bits), and then that assert fails.
But, the mechanism to fix that is already present. If you look more
carefully at the #if statement you will see this at the end:
!defined(NS_PTR_LE_32)
That macro is for 64-bit architectures that use 32-bit pointers, which
is exactly the case of MIPS64 n32. So, to fix the problem we only need
to detect when we are building for MIPS64 n32, and then define that
macro so the #if statement will fail and the #else will be executed
instead. Here you have a patch that I have already tested to check if
it works, and it worked. The thing is that I don't know where is the
best place to put those lines, so I would like a bit of feedback here.
The better fix is to add NS_PTR_LE_32 the Makefile in freebl (that's
where most of the platform dependent choices are made).
ifeq ($CPU_ARCH,mips) # or whatever the appropriate define is for
mips64 n32.
DEFINES += -DNS_PTR_LE_32
endif
There may be new checks in nss freebl that have the same character.
Better to make the definition more general.
AFAIK this is the first platform the actually required the NS_PTR_LE_32
or NS_PTR_GT_32 define.
bob
Hello bob,
this patch would fix the problem for native compilations:
################## BEGIN PATCH ####################
diff -rup a/mozilla/security/nss/lib/freebl/Makefile
b/mozilla/security/nss/lib/freebl/Makefile
--- a/mozilla/security/nss/lib/freebl/Makefile 2013-01-31
01:08:59.000000000 +0000
+++ b/mozilla/security/nss/lib/freebl/Makefile 2014-05-14
10:31:02.622338772 +0100
@@ -206,6 +206,11 @@ ifeq ($(CPU_ARCH),arm)
DEFINES += -DSHA_NO_LONG_LONG # avoid 64-bit arithmetic in SHA512
MPI_SRCS += mpi_arm.c
endif
+ifeq ($(CPU_ARCH),mips64)
+ifeq ($(USE_N32),1)
+ DEFINES += -DNS_PTR_LE_32
+endif
+endif
endif # Linux
ifeq ($(OS_TARGET),AIX)
################### END PATCH #####################
The user would need to pass USE_N32=1 to the make command, but I think
that's reasonable.
Now we have another problem. That will fail when cross-compiling because
the $CPU_ARCH variable comes from $OS_TEST (see
mozilla/security/coreconf/Linux.mk for details) which comes from `uname
-m` (see mozilla/security/coreconf/arch.mk for details). So, when you
are cross-compiling the result of `uname -m` is the architecture of the
host machine, not the target machine.
Could be possible to add another user-defined variable to set the target
architecture and do something like this in the Linux.mk file?
ifdef($TARGET_ARCH)
CPU_ARCH=$TARGET_ARCH
else
CPU_ARCH=$OS_TEST
endif
In that case the use would need to pass TARGET_ARCH=mips64 to the make
command. (mips64 is just an example in this case)
diff -rup a/mozilla/security/nss/lib/freebl/drbg.c
b/mozilla/security/nss/lib/freebl/drbg.c
--- a/mozilla/security/nss/lib/freebl/drbg.c 2012-12-12
19:22:39.000000000 +0000
+++ b/mozilla/security/nss/lib/freebl/drbg.c 2014-05-13
11:24:32.100993252 +0100
@@ -485,6 +485,10 @@ RNG_RandomUpdate(const void *data, size_
/* Make sure our assumption that size_t is unsigned is true */
PR_STATIC_ASSERT(((size_t)-1) > (size_t)1);
+#if defined(__mips__) && defined(_ABIN32)
+#define NS_PTR_LE_32
+#endif
+
#if defined(NS_PTR_GT_32) || (defined(NSS_USE_64) &&
!defined(NS_PTR_LE_32))
/*
* NIST 800-90 requires us to verify our inputs. This value can
On 05/13/2014 09:16 AM, Vicente Olivert Riera wrote:
On 05/13/2014 01:56 AM, Paul Wouters wrote:
On Mon, 12 May 2014, Vicente Olivert Riera wrote:
Are you compiling natively? Or cross compiling? This is on my todo
list
(as prereq for libreswan) but after a quick first attempt and seeing
that it compiles/runs some code with no check that it is cross
compiling
had demotivated me enough to postpone it.
Hi Paul,
I'm cross compiling.
Hmm, interesting. If you do get it to work let me know. If I pick this
up again in a few weeks and make it work, I'll let you know.
It works on MIPS32 and MIPS64 n64 ABI. It only fails on MIPS64 n32 ABI.
Maybe it's not a bug of NSS but NSPR. Please have a look to this thread
which is about the same failure (and there is a patch at the end to fix
it):
http://lists.busybox.net/pipermail/buildroot/2013-March/068973.html
patch: nspr-prcpucfg-aarch64.patch
http://pastie.org/6606946
Paul
Paul
Date: Mon, 12 May 2014 11:33:13
From: Vicente Olivert Riera <vincent.ri...@imgtec.com>
To: dev-tech-crypto@lists.mozilla.org
Subject: NSS fails to compile on MIPS64 n32 platforms
I'm trying to build NSS-3.14.5 on Buildroot for MIPS54 n32 ABI
and I'm
getting this compilation failure:
################################################
In file included from
/home/test/test/1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/usr/include/nspr/prerror.h:9:0,
from drbg.c:10:
drbg.c: In function 'RNG_RandomUpdate':
/home/test/test/1/output/host/usr/mips64el-buildroot-linux-gnu/sysroot/usr/include/nspr/prtypes.h:560:38:
error: size of array 'arg' is negative
extern void pr_static_assert(int arg[(condition) ? 1 : -1])
^
drbg.c:512:5: note: in expansion of macro 'PR_STATIC_ASSERT'
PR_STATIC_ASSERT(sizeof(size_t) > 4);
^
make[4]: ***
[Linux2.6_mips64el_glibc_PTH_64_OPT.OBJ/Linux_SINGLE_SHLIB/drbg.o]
Error 1
################################################
This is the full build log:
http://autobuild.buildroot.net/results/0e3/0e3f1482d6f2f9bddc53d4e78b575120a2729e1d/build-end.log
I also tried NSS-3.16.1 and I got the same result.
--
Vincent
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Vincent
--
Vincent
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
