NSPR uses preprocessor definitions like __x86_64__ to guess implementation details like type sizes, and to know which version of assembly code to compile. This makes it guess the wrong type sizes on x32, and compile the 64-bit version of assembly code. It succeeds to build, but the result is incorrect, and can't even be linked to. Reproducible: Always
Created attachment 315841 [details, diff] patch for x32 support This patch fixes x32 to build properly on x32. It basically makes it treat x32 as x86, including building x86 assembly for atomic operations. I've run some part of the test suite and the atomic test passes, at least (the test suite takes a long time). Tested with my upcoming patch for NSS x32 support. Succeeds establishing both SSL client and server connections, with some software of mine.
Created attachment 315933 [details, diff] x32 support using LP64 I rather you test this patch and report problems please, it is alot cleaner then your current method.
The patch works.
(In reply to comment #3) > The patch works. Thanks for testing, I will commit it to tree later tonight.
Thanks for testing, I am reviewing your nss changes and will commit it all together from the mozilla overlay.
I am reopening as I will need to update the patch for x32. I overlooked the atomicop fixes you had which are indeed needed.
I've noticed this, however it still compiles, and the atomic test passes. I've also done a simple test to verify that Increment does not accidentaly write 8 bytes instead of 4 (corruping data that follows). So I think we're fine. If you want to run the test suite, don't forget to pass --enable-64bit to configure to make sure it doesn't compile with -m32 (yes, it sounds reverse), and make sure it's actually compiling without -m32. Also, the test suite script seems broken; you will probably want to run any tests directly.
(In reply to comment #7) > I've noticed this, however it still compiles, and the atomic test passes. > I've also done a simple test to verify that Increment does not accidentaly > write 8 bytes instead of 4 (corruping data that follows). So I think we're > fine. > > If you want to run the test suite, don't forget to pass --enable-64bit to > configure to make sure it doesn't compile with -m32 (yes, it sounds > reverse), and make sure it's actually compiling without -m32. Also, the test > suite script seems broken; you will probably want to run any tests directly. You will end up with symbols missing which will break compilation on packages like spidermonkey, which is fixed in mozilla overlay. Either way I will include the bits to ensure we are not seeing failure to do undefined references.
I see, you're right. On x86_64: # nm -D /usr/lib/libnspr4.so.9 |grep -i atomic 0000000000016720 T PR_AtomicAdd 0000000000016700 T PR_AtomicDecrement 00000000000166f0 T PR_AtomicIncrement 0000000000016710 T PR_AtomicSet 000000000002c6b8 T _PR_x86_64_AtomicAdd 000000000002c6a4 T _PR_x86_64_AtomicDecrement 000000000002c698 T _PR_x86_64_AtomicIncrement 000000000002c6b0 T _PR_x86_64_AtomicSet On x32 with your patch: # nm -D /usr/libx32/libnspr4.so.9 |grep -i atomic 00014cf0 T PR_AtomicAdd 00014cd0 T PR_AtomicDecrement 00014cc0 T PR_AtomicIncrement 00014ce0 T PR_AtomicSet U _PR_x86_64_AtomicAdd U _PR_x86_64_AtomicDecrement U _PR_x86_64_AtomicIncrement U _PR_x86_64_AtomicSet 0002b3c0 T _PR_x86_AtomicAdd 0002b39c T _PR_x86_AtomicDecrement 0002b388 T _PR_x86_AtomicIncrement 0002b3b0 T _PR_x86_AtomicSet On x32 with my patch: # nm -D /usr/libx32/libnspr4.so.9 |grep -i atomic 00014c30 T PR_AtomicAdd 00014c10 T PR_AtomicDecrement 00014c00 T PR_AtomicIncrement 00014c20 T PR_AtomicSet 0002b300 T _PR_x86_AtomicAdd 0002b2dc T _PR_x86_AtomicDecrement 0002b2c8 T _PR_x86_AtomicIncrement 0002b2f0 T _PR_x86_AtomicSet So, the logic in my patch seems correct; you should be able to adapt to using __LP64__ if for some reason you don't like __ILP32__.
-r2 was committed to the tree, closing now.
Reopening, after working with upstream we will go a completely different way with this and make it much faster for all.
To give those an ideal of what we are working on I will explain. We will patch _linux.cfg, we will not patch _linux.h, what should be happening is we should be use --enable-64bit which would use the 64bit assembly instead of using x86 assembly. I have already reworked the ebuild in my chroot and tested it, refer to output on atomic ops. nm -D /usr/libx32/libnspr4.so.9 | grep -i atomic 00015510 T PR_AtomicAdd 000154b0 T PR_AtomicDecrement 00015480 T PR_AtomicIncrement 000154e0 T PR_AtomicSet 00030180 T _PR_x86_64_AtomicAdd 0003016c T _PR_x86_64_AtomicDecrement 00030160 T _PR_x86_64_AtomicIncrement 00030178 T _PR_x86_64_AtomicSet
If someone would test nss from mozilla overlay would be appreciated. Once we have a bit of feedback we will move to the official tree.
(In reply to comment #13) > If someone would test nss from mozilla overlay would be appreciated. Once we > have a bit of feedback we will move to the official tree. err s/nss/nspr
4.9.2 has full support, support will change in the future to --enable-x32 or something along them lines upstream at which time we will rework the support in gentoo.
