On 05/14/2014 03:57 AM, Vicente Olivert Riera wrote: > 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 #####################
Please write a bug on this (mozilla.bugzilla.com), attach this patch and request a review from me (rrelyea). We can get this upstream. Thanks, bob > > 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) We usually do cross compiles by creating a cross target .mk file (MIPS_CROSS.mk for instance). You can include linux.mk and explicitly set the CPU_ARCH inside there. (see android.mk). bob > >>> >>> >>> >>> 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 >>>>>> >>>> >>>> >>> >>> >> >> >> >> > >
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
