Last Comment Bug 266123 - nss-3.9.2 produces segmention faults when trying to compile on ppc64
: nss-3.9.2 produces segmention faults when trying to compile on ppc64
Status: RESOLVED FIXED
: fixed1.8
Product: NSS
Classification: Components
Component: Build (show other bugs)
: 3.0
: All All
: -- normal (vote)
: 3.11
Assigned To: Wan-Teh Chang
: Wan-Teh Chang
Mentors:
: 316490 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-26 06:52 PDT by markusr815
Modified: 2005-11-15 18:46 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
nss-3.9.2 compile output (3.41 KB, text/plain)
2004-10-26 06:55 PDT, markusr815
no flags Details
coreconfig patch 1 (526 bytes, patch)
2004-10-26 06:57 PDT, markusr815
wtc: review+
Details | Diff | Review
strace output (23.08 KB, text/plain)
2004-10-27 02:18 PDT, markusr815
no flags Details
nspr ppc64 patch 1 (1.52 KB, patch)
2004-10-27 02:22 PDT, markusr815
no flags Details | Diff | Review
nspr ppc64 patch 2 (422 bytes, patch)
2004-10-27 02:22 PDT, markusr815
no flags Details | Diff | Review
nspr ppc64 patch 1 (1.54 KB, patch)
2004-10-28 08:31 PDT, markusr815
wtc: review+
Details | Diff | Review
nspr ppc64 patch 2 (451 bytes, patch)
2004-10-28 08:32 PDT, markusr815
wtc: review+
Details | Diff | Review
stack trace (2.66 KB, text/plain)
2004-10-28 09:14 PDT, markusr815
no flags Details
stack trace (2.14 KB, text/plain)
2004-10-29 05:41 PDT, markusr815
no flags Details
64-bit PowerPC build support (2.95 KB, patch)
2005-08-11 13:29 PDT, Wan-Teh Chang
cls: review+
asa: approval1.8b4+
Details | Diff | Review
nspr ppc64 patch 3 (fixed differently in nspr 4.6. see bug 238842) (653 bytes, patch)
2005-08-12 00:06 PDT, markusr815
wtc: review+
Details | Diff | Review

Description markusr815 2004-10-26 06:52:10 PDT
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
Comment 1 markusr815 2004-10-26 06:55:31 PDT
Created attachment 163427 [details]
nss-3.9.2 compile output

the output
Comment 2 markusr815 2004-10-26 06:57:47 PDT
Created attachment 163428 [details] [diff] [review]
coreconfig patch 1

I also applied this patch...

Markus
Comment 3 Wan-Teh Chang 2004-10-26 10:20:18 PDT
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.
Comment 4 markusr815 2004-10-26 11:11:30 PDT
ok.. I'll try that.  Could take some days, before I have the knowledge to do that ;-)  Markus
Comment 5 markusr815 2004-10-27 02:18:40 PDT
Created attachment 163544 [details]
strace output

I hope this is what you wanted...

markus
Comment 6 markusr815 2004-10-27 02:22:22 PDT
Created attachment 163545 [details] [diff] [review]
nspr ppc64 patch 1
Comment 7 markusr815 2004-10-27 02:22:58 PDT
Created attachment 163546 [details] [diff] [review]
nspr ppc64 patch 2
Comment 8 Wan-Teh Chang 2004-10-27 15:24:22 PDT
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 9 Wan-Teh Chang 2004-10-27 15:26:14 PDT
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__.
Comment 10 markusr815 2004-10-28 08:31:32 PDT
Created attachment 163703 [details] [diff] [review]
nspr ppc64 patch 1
Comment 11 markusr815 2004-10-28 08:32:08 PDT
Created attachment 163704 [details] [diff] [review]
nspr ppc64 patch 2
Comment 12 markusr815 2004-10-28 08:37:21 PDT
uhm.. yes! you are absolutly right. __powerpc__ is also defined. fixed that. 
 
The stack trace: Trying to get that correct one now. 
 
markus 
Comment 13 markusr815 2004-10-28 09:14:50 PDT
Created attachment 163707 [details]
stack trace

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

markus
Comment 14 Wan-Teh Chang 2004-10-28 14:38:21 PDT
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.
Comment 15 markusr815 2004-10-29 05:41:01 PDT
Created attachment 163823 [details]
stack trace

I've tried that. Here it is.

Markus
Comment 16 markusr815 2004-10-30 07:29:56 PDT
I'm stuck and need help.. :-/ 
 
I realy cannot figure out, why this segmention faults happen... 
 
Markus 
Comment 17 markusr815 2004-11-09 11:48:21 PST
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
Comment 18 markusr815 2004-11-09 11:49:25 PST
s/think/thing ;-)
Comment 19 Tom Gall 2004-11-14 11:43:45 PST
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. 
Comment 20 Wan-Teh Chang 2004-11-18 15:30:16 PST
Please try the patch (attachment 166362 [details] [diff] [review]) in bug 270502.
It's for a different architecture (s390x), but worth a
try.
Comment 21 markusr815 2005-03-06 10:07:07 PST
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. 
Comment 22 markusr815 2005-08-06 11:21:18 PDT
are there any reasons why this patches are not applied yet? They make it
possible to use nspr and nss.
Comment 23 Wan-Teh Chang 2005-08-09 15:32:50 PDT
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.
Comment 24 Wan-Teh Chang 2005-08-09 15:43:11 PDT
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.
Comment 25 Wan-Teh Chang 2005-08-09 15:45:27 PDT
Markus: have you verified that 32-bit "ppc" build still
works with these three patches applied?
Comment 26 Wan-Teh Chang 2005-08-11 13:29:00 PDT
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.
Comment 27 markusr815 2005-08-12 00:05:14 PDT
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 28 markusr815 2005-08-12 00:06:04 PDT
Created attachment 192492 [details] [diff] [review]
nspr ppc64 patch 3 (fixed differently in nspr 4.6. see bug 238842)
Comment 29 Wan-Teh Chang 2005-08-12 09:29:56 PDT
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/).
Comment 30 markusr815 2005-08-12 11:33:02 PDT
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 31 Wan-Teh Chang 2005-08-18 11:04:58 PDT
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.
Comment 32 markusr815 2005-08-20 03:34:03 PDT
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.
Comment 33 Wan-Teh Chang 2005-08-22 13:27:28 PDT
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.
Comment 34 Wan-Teh Chang 2005-08-24 16:27:27 PDT
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.
Comment 35 Wan-Teh Chang 2005-11-15 18:46:06 PST
*** Bug 316490 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.