Closed Bug 266123 Opened 17 years ago Closed 16 years ago
.9 .2 produces segmention faults when trying to compile on ppc64
3.41 KB, text/plain
23.08 KB, text/plain
1.54 KB, patch
|Details | Diff | Splinter Review|
451 bytes, patch
|Details | Diff | Splinter Review|
2.14 KB, text/plain
2.95 KB, patch
|Details | Diff | Splinter Review|
653 bytes, patch
|Details | Diff | Splinter Review|
User-Agent: Links (2.1pre15; Linux 2.6.9-gentoo-r1 ppc64; 228x82) Build Identifier: Hi, I would like to see nss compiling on ppc64. I use Gentoo Linux. I am using gcc-3.4.1 (including ICE patch for mozilla on ppc64). Output follows.. Markus Reproducible: Always Steps to Reproduce: 1.try to compile nss-3.9.2 on ppc64 2. 3. Actual Results: compile fails Expected Results: compile succedes
I also applied this patch... Markus
Markus, could you get a stack trace from the core file dumped by shlibsign? I suggest that you begin the ppc64 porting with NSPR. Looking at mozilla/nsprpub/pr/include/md/_linux.cfg, I only see __powerpc__ being tested. So it seems that NSPR hasn't been ported to ppc64 yet.
ok.. I'll try that. Could take some days, before I have the knowledge to do that ;-) Markus
Attachment #163428 - Attachment description: ppc64 patch → ppc64 patch 1
I hope this is what you wanted... markus
Attachment #163428 - Attachment description: ppc64 patch 1 → coreconfig patch 1
Comment on attachment 163544 [details] strace output Hi. This is a system call trace. What I need is a stack trace that shows the call stack when shlibsign crashed. If shlibsign dumped core, you can invoke gdb on it: gdb <path of shlibsign> <core file name> and then use the "where" command in gdb to get the stack trace.
Comment on attachment 163545 [details] [diff] [review] nspr ppc64 patch 1 Is the __powerpc__ macro defined on ppc64? If so, we will need to test for __powerpc64__ before __powerpc__.
uhm.. yes! you are absolutly right. __powerpc__ is also defined. fixed that. The stack trace: Trying to get that correct one now. markus
mhh.. this doesn't help, does it? markus
Please try invoking gdb on the core file as follows: % cd /var/tmp/portage/nss-3.9.2/work/nss-3.9.2/mozilla/security/nss/cmd/shlibsign % gdb Linux2.6_ppc64_glibc_PTH_OPT.OBJ/shlibsign core This will get rid of the error messages like: Error while mapping shared library sections: ../../../dist/Linux2.6_ppc64_glibc_PTH_OPT.OBJ/lib/libssl3.so: No such file or directory. I don't know if it will help you get a better stack trace though.
I've tried that. Here it is. Markus
Attachment #163707 - Attachment is obsolete: true
I'm stuck and need help.. :-/ I realy cannot figure out, why this segmention faults happen... Markus
ok... I have done some testing and found the think, which caused this: I had to recompile glibc with nptl support and the segmention faults were gone.. So we have to use a nptl enabled glibc on ppc64? And should the above patches go upstream? Markus
OS: Linux → All
Hardware: Macintosh → All
Version: 3.9.2 → 3.0
Severity: major → blocker
I've been attempting to build this on ppc64 as well much the same way that Markus is doing so. Consistantly the build segfaults when running : Linux2.6_ppc64_glibc_PTH_OPT.OBJ/shlibsign -v -i ../../../dist/Linux2.6_ppc64_glibc_PTH_OPT.OBJ/lib/libsoftokn3.so Doesn't matter if I'm using a version glibc that's build with nptl only or both with pthreads and ntpl. I'm slowly starting to debug (but the build system for nss seems to be a bit obscure) in shlibsign.c the following call is where it's SIGSEGV'ing rv = NSS_NoDB_Init(""); So somewhere in this library in the call path is not right. When it SEGVs, from gdb I can see it doesn't have a reasonable call stack. It feels like the stack has somehow gotten currupted. Tho the address in the lr looks reasonable.
Please try the patch (attachment 166362 [details] [diff] [review]) in bug 270502. It's for a different architecture (s390x), but worth a try.
The above three patches and using gcc-3.4.3 solve this problem. Though I don't understand, why gcc-3.4.3 solved it. Anyway, please apply the above three patches so that nss/nspr/mozilla compile on ppc64 (coreconfig patch 1; nspr ppc64 patch 1; nspr ppc64 patch2). Though mozilla won't run, because we need to port xptcall to ppc64. But that's another bug to solve... Applying this three patches are a step in the right way.
are there any reasons why this patches are not applied yet? They make it possible to use nspr and nss.
Comment on attachment 163428 [details] [diff] [review] coreconfig patch 1 r=wtc. I checked in this patch on the NSS trunk (NSS 3.11). Checking in Linux.mk; /cvsroot/mozilla/security/coreconf/Linux.mk,v <-- Linux.mk new revision: 1.20; previous revision: 1.19 done This will eventually appear in the version of NSS used by the Mozilla clients, hopefully by the end of Oct. 2005.
Attachment #163428 - Flags: review+
Comment on attachment 163704 [details] [diff] [review] nspr ppc64 patch 2 r=wtc. I checked in the two NSPR patches on the NSPR trunk (NSPR 4.6.1). Checking in _linux.cfg; /cvsroot/mozilla/nsprpub/pr/include/md/_linux.cfg,v <-- _linux.cfg new revision: 3.18; previous revision: 3.17 done Checking in _linux.h; /cvsroot/mozilla/nsprpub/pr/include/md/_linux.h,v <-- _linux.h new revision: 3.45; previous revision: 3.44 done These patches will eventually appear in the version of NSPR used by the Mozilla clients, hopefully by the end of Sept. 2005.
Attachment #163704 - Flags: review+
Markus: have you verified that 32-bit "ppc" build still works with these three patches applied?
Severity: blocker → normal
Target Milestone: --- → 3.11
I did some testing on both ppc and ppc64 systems, running Red Hat Enterprise Linux 3, 4, and Fedora Core 3. I found that the coreconf patch (attachment 163428 [details] [diff] [review]) is incomplete because the GCC on RHEL ppc64 systems generates 32-bit binaries by default. I don't know if that's also the default on other Linux distributions. This patch adds 64-bit Linux/ppc64 build support to both NSPR and NSS.
I just wanted to write, that I got someone who has tested the pathes on a ppc system. According to his tests mozilla compiles and operates normaly. Also I have missed a small patch, which I will add to this bug. A comment to your patch: This seems to be a RedHat problem. On my gentoo system my patch is sufficient to generate 64bit binaries: # file /usr/lib64/nspr/libnspr4.so /usr/lib64/nspr/libnspr4.so: ELF 64-bit MSB shared object, cisco 7500, version 1 (SYSV), not stripped
Comment on attachment 192492 [details] [diff] [review] nspr ppc64 patch 3 (fixed differently in nspr 4.6. see bug 238842) Markus: could you post the output of "gcc -v" on your Gentoo system? On Red Hat Enterprise Linux 4, "gcc -v" says: Reading specs from /usr/lib/gcc/ppc64-redhat-linux/3.4.4/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/u sr/share/info --enable-shared --enable-threads=posix --disable-checking --with-s ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-aw t=gtk --host=ppc64-redhat-linux --build=ppc64-redhat-linux --target=ppc64-redhat -linux --with-cpu=default32 Thread model: posix gcc version 3.4.4 20050721 (Red Hat 3.4.4-2) Note the --with-cpu=default32 option. I guess that's why it generates 32-bit binaries by default. If you say "gcc -m32 foo.c", does it generate 32-bit binaries? Thanks for submitting this NSPR patch for prprf.c. This patch is correct. The VARARGS_ASSIGN macro, which copies a va_list, was a big porting problem, so I eliminated it in NSPR 4.6. It is fine to apply your patch to NSPR 4.5.x or older. It is better to upgrade to NSPR 4.6 (CVS tag NSPR_4_6_RTM. FTP site ftp://ftp.mozilla.org/pub/mozilla.org/nspr/releases/v4.6/).
yes, --with-cpu=default32 seems to be the problem on Red Hat. Do they have 32bit or 64bit userland? I mean it would be stupid to have a 64bit userland and gcc compiled with --with-cpu=default32. So I think it would be fine without your modification, would it? Here is the output from gcc on Gentoo Linux: Reading specs from /usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.4/specs Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/powerpc64-unknown-linux-gnu/gcc-bin/3.4.4 --includedir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.4/include --datadir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/3.4.4 --mandir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/3.4.4/include/g++-v3 --host=powerpc64-unknown-linux-gnu --build=powerpc64-unknown-linux-gnu --enable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,objc,f77 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)
Comment on attachment 192412 [details] [diff] [review] 64-bit PowerPC build support I am requesting mozilla1.8b4 approval for this build system enhancement. This patch enables one to do 64-bit PowerPC builds on Linux distributions whose GCC generates 32-bit code by default (such as Red Hat and Fedora). This patch doesn't affect any other platforms, including Linux on non-PowerPC architectures.
Attachment #192412 - Flags: approval1.8b4?
No, I don't think this is the correct way to do it. If the compiler generates 32 bit code by default, then let it generate 32 bit code by default. The whole system seems to be compiled with 32 bit if the compiler generates 32 bit code by default. So why should mozilla be forced to use 64 bit? Your patch does not look correct for me.
Markus: my patch enables one to do a 64-bit build of NSPR and NSS if the compiler generates 32-bit code by default. It still allows one to do a 32-bit build of NSPR and NSS with those compilers. It doesn't force Mozilla to use 64 bit. When NSPR and NSS are built as part of Mozilla, the Mozilla build system will pass the appropriate build options to NSPR and NSS to ensure that everything is built as either 32 bit or 64 bit.
Attachment #192412 - Flags: approval1.8b4? → approval1.8b4+
Comment on attachment 192412 [details] [diff] [review] 64-bit PowerPC build support I checked in the NSPR change in this patch on the MOZILLA_1_8_BRANCH for mozilla1.8b4.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
*** Bug 316490 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.