Closed
Bug 266123
Opened 20 years ago
Closed 19 years ago
nss-3.9.2 produces segmention faults when trying to compile on ppc64
Categories
(NSS :: Build, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
3.11
People
(Reporter: o586806, Assigned: wtc)
References
Details
(Keywords: fixed1.8)
Attachments
(7 files, 4 obsolete files)
3.41 KB,
text/plain
|
Details | |
23.08 KB,
text/plain
|
Details | |
1.54 KB,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
451 bytes,
patch
|
wtc
:
review+
|
Details | Diff | Splinter Review |
2.14 KB,
text/plain
|
Details | |
2.95 KB,
patch
|
cls
:
review+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
653 bytes,
patch
|
wtc
:
review+
|
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
Assignee | ||
Comment 3•20 years ago
|
||
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
Attachment #163428 -
Attachment description: ppc64 patch 1 → coreconfig patch 1
Assignee | ||
Comment 8•20 years ago
|
||
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.
Assignee | ||
Comment 9•20 years ago
|
||
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__.
Reporter | ||
Comment 10•20 years ago
|
||
Attachment #163545 -
Attachment is obsolete: true
Reporter | ||
Comment 11•20 years ago
|
||
Attachment #163546 -
Attachment is obsolete: true
Reporter | ||
Comment 12•20 years ago
|
||
uhm.. yes! you are absolutly right. __powerpc__ is also defined. fixed that. The stack trace: Trying to get that correct one now. markus
Reporter | ||
Comment 13•20 years ago
|
||
mhh.. this doesn't help, does it? markus
Assignee | ||
Comment 14•20 years ago
|
||
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.
Reporter | ||
Comment 15•20 years ago
|
||
I've tried that. Here it is. Markus
Attachment #163707 -
Attachment is obsolete: true
Reporter | ||
Comment 16•20 years ago
|
||
I'm stuck and need help.. :-/ I realy cannot figure out, why this segmention faults happen... Markus
Reporter | ||
Comment 17•20 years ago
|
||
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
Comment 19•20 years ago
|
||
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.
Assignee | ||
Comment 20•20 years ago
|
||
Please try the patch (attachment 166362 [details] [diff] [review]) in bug 270502. It's for a different architecture (s390x), but worth a try.
Reporter | ||
Comment 21•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Reporter | ||
Comment 22•19 years ago
|
||
are there any reasons why this patches are not applied yet? They make it possible to use nspr and nss.
Assignee | ||
Comment 23•19 years ago
|
||
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+
Assignee | ||
Updated•19 years ago
|
Attachment #163703 -
Flags: review+
Assignee | ||
Comment 24•19 years ago
|
||
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+
Assignee | ||
Comment 25•19 years ago
|
||
Markus: have you verified that 32-bit "ppc" build still works with these three patches applied?
Severity: blocker → normal
Target Milestone: --- → 3.11
Assignee | ||
Comment 26•19 years ago
|
||
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.
Attachment #163428 -
Attachment is obsolete: true
Attachment #192412 -
Flags: review?(cls)
Reporter | ||
Comment 27•19 years ago
|
||
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
Reporter | ||
Comment 28•19 years ago
|
||
Assignee | ||
Comment 29•19 years ago
|
||
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/).
Attachment #192492 -
Attachment description: nspr ppc64 patch 3 → nspr ppc64 patch 3 (fixed differently in nspr 4.6. see bug 238842)
Attachment #192492 -
Flags: review+
Reporter | ||
Comment 30•19 years ago
|
||
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)
Attachment #192412 -
Flags: review?(cls) → review+
Assignee | ||
Comment 31•19 years ago
|
||
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?
Reporter | ||
Comment 32•19 years ago
|
||
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.
Assignee | ||
Comment 33•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking1.8b4+
Updated•19 years ago
|
Attachment #192412 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 34•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Flags: blocking1.8b4+
Resolution: --- → FIXED
Assignee | ||
Comment 35•19 years ago
|
||
*** 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.
Description
•