Closed Bug 266123 Opened 17 years ago Closed 16 years ago

nss-3.9.2 produces segmention faults when trying to compile on ppc64


(NSS :: Build, defect)

Not set


(Not tracked)



(Reporter: o586806, Assigned: wtc)



(Keywords: fixed1.8)


(7 files, 4 obsolete files)

User-Agent:       Links (2.1pre15; Linux 2.6.9-gentoo-r1 ppc64; 228x82)
Build Identifier: 


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..


Reproducible: Always
Steps to Reproduce:
1.try to compile nss-3.9.2 on ppc64

Actual Results:  
compile fails

Expected Results:  
compile succedes
the output
Attached patch coreconfig patch 1 (obsolete) — Splinter Review
I also applied this patch...

Version: unspecified → 3.9.2
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
Attached file strace output
I hope this is what you wanted...

Attachment #163428 - Attachment description: ppc64 patch 1 → coreconfig patch 1
Attached patch nspr ppc64 patch 1 (obsolete) — Splinter Review
Attached patch nspr ppc64 patch 2 (obsolete) — Splinter Review
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
Attachment #163545 - Attachment is obsolete: true
Attachment #163546 - Attachment is obsolete: true
uhm.. yes! you are absolutly right. __powerpc__ is also defined. fixed that. 
The stack trace: Trying to get that correct one now. 
Attached file stack trace (obsolete) —
mhh.. this doesn't help, does it?

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/ No such file or

I don't know if it will help you get a better stack
trace though.
Attached file stack trace
I've tried that. Here it is.

Attachment #163707 - Attachment is obsolete: true
I'm stuck and need help.. :-/ 
I realy cannot figure out, why this segmention faults happen... 
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
s/think/thing ;-)
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

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

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
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. 
Ever confirmed: true
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;
/cvsroot/mozilla/security/coreconf/,v  <--
new revision: 1.20; previous revision: 1.19

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+
Attachment #163703 - 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
Checking in _linux.h;
/cvsroot/mozilla/nsprpub/pr/include/md/_linux.h,v  <--	_linux.h
new revision: 3.45; previous revision: 3.44

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
Attachment #163428 - Attachment is obsolete: true
Attachment #192412 - Flags: review?(cls)
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/ 
/usr/lib64/nspr/ 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
sr/share/info --enable-shared --enable-threads=posix --disable-checking
ystem-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
t=gtk --host=ppc64-redhat-linux --build=ppc64-redhat-linux
-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
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+
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
--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+
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.
Flags: blocking1.8b4+
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.
Closed: 16 years ago
Flags: blocking1.8b4+
Resolution: --- → FIXED
Keywords: fixed1.8
*** 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.