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

RESOLVED FIXED in 3.11

Status

NSS
Build
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: o586806, Assigned: Wan-Teh Chang)

Tracking

({fixed1.8})

3.11
fixed1.8

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments, 4 obsolete attachments)

(Reporter)

Description

13 years ago
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
(Reporter)

Comment 1

13 years ago
Created attachment 163427 [details]
nss-3.9.2 compile output

the output
(Reporter)

Comment 2

13 years ago
Created attachment 163428 [details] [diff] [review]
coreconfig patch 1

I also applied this patch...

Markus
(Reporter)

Updated

13 years ago
Version: unspecified → 3.9.2
(Assignee)

Comment 3

13 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.
(Reporter)

Comment 4

13 years ago
ok.. I'll try that.  Could take some days, before I have the knowledge to do that ;-)  Markus
(Reporter)

Updated

13 years ago
Attachment #163428 - Attachment description: ppc64 patch → ppc64 patch 1
(Reporter)

Comment 5

13 years ago
Created attachment 163544 [details]
strace output

I hope this is what you wanted...

markus
(Reporter)

Updated

13 years ago
Attachment #163428 - Attachment description: ppc64 patch 1 → coreconfig patch 1
(Reporter)

Comment 6

13 years ago
Created attachment 163545 [details] [diff] [review]
nspr ppc64 patch 1
(Reporter)

Comment 7

13 years ago
Created attachment 163546 [details] [diff] [review]
nspr ppc64 patch 2
(Assignee)

Comment 8

13 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

13 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

13 years ago
Created attachment 163703 [details] [diff] [review]
nspr ppc64 patch 1
Attachment #163545 - Attachment is obsolete: true
(Reporter)

Comment 11

13 years ago
Created attachment 163704 [details] [diff] [review]
nspr ppc64 patch 2
Attachment #163546 - Attachment is obsolete: true
(Reporter)

Comment 12

13 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

13 years ago
Created attachment 163707 [details]
stack trace

mhh.. this doesn't help, does it?

markus
(Assignee)

Comment 14

13 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

13 years ago
Created attachment 163823 [details]
stack trace

I've tried that. Here it is.

Markus
Attachment #163707 - Attachment is obsolete: true
(Reporter)

Comment 16

13 years ago
I'm stuck and need help.. :-/ 
 
I realy cannot figure out, why this segmention faults happen... 
 
Markus 
(Reporter)

Comment 17

13 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
(Reporter)

Comment 18

13 years ago
s/think/thing ;-)
Severity: major → blocker

Comment 19

13 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

13 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

13 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

13 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Reporter)

Comment 22

12 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

12 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

12 years ago
Attachment #163703 - Flags: review+
(Assignee)

Comment 24

12 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

12 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

12 years ago
Created attachment 192412 [details] [diff] [review]
64-bit PowerPC build support

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

12 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

12 years ago
Created attachment 192492 [details] [diff] [review]
nspr ppc64 patch 3 (fixed differently in nspr 4.6. see bug 238842)
(Assignee)

Comment 29

12 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

12 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)

Updated

12 years ago
Attachment #192412 - Flags: review?(cls) → review+
(Assignee)

Comment 31

12 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

12 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

12 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

12 years ago
Flags: blocking1.8b4+

Updated

12 years ago
Attachment #192412 - Flags: approval1.8b4? → approval1.8b4+
(Assignee)

Comment 34

12 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

12 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Flags: blocking1.8b4+
Resolution: --- → FIXED

Updated

12 years ago
Keywords: fixed1.8
(Assignee)

Comment 35

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