80082 - Need to properly integrate libnspr_flt4.so (was: libultrasparc4.so)

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Rich Burridge]

In .../mozilla/nsprpub/pr/src/md/unix, on Solaris SPARC machines, if
built on an UltraSPARC machine, a libultrasparc4.so library is generated
which contains UltraSPARC specific assembler. If there is a symbolic link
libatomic.so to this library, then about 10% better performance is achieved
on UltraSPARC machines.

There needs to be a better way to integrate this into a Solaris SPARC
distribution. After thinking about this some more, there is a problem, 
with the idea on setting up that symbolic link if you are installing on 
an UltraSPARC machine. What if this was an enterprise install, then a
non-UltraSPARC user tried to run Mozilla/Netscape 6.5 from the same
directory? BOOM!

I chatted with one of the Unix wizards on IRC here at Sun, and he
suggested the following. Perhaps there is a simple way of doing this.
Apologies if I've misunderstood how libatomic.so is used.

----

<rfm>There is serious linker magic called processor specific filters that 
     allow you to do all this automatically at runtime.  You may not even 
     need a filter -- is libultrasparc.so a complete replacement for whatever
     libatomic.so points to on a non-ultrasparc?
<richb> rfm: yes (the alternative is a generic C routine).
<rfm> Hang on I need to find the right section of the linker manual to point 
      you to
<rfm> What's the earliest OS you're targeting?  2.6?
<richb> rfm: Solaris 7.
<rfm> Oh good
<richb> rfm: actually, i might be misleading you here. The way this works 
        is the code looks for and tries to dlopen() a libatomic.so if it's
        present. if that fails, it does the operation the "slow" way (with 
        a C routine). Hang on, I'll try to get you an LXR reference...
<rfm> Here it is:
<rfm> Look for the section "Instruction Set Specific Shared Objects" in the 
linker and
<rfm> libraries manual.  
<richb> rfm: what page are you on? I have a copy of that here.
<rfm> I think in this case what you do is put it in
      /$PKGROOT/lib/sparcv8plus/libatomic.so
<rfm> then put /$PKGROOT/lib/$ISALIST/libatomic.so in your LD_RUN_PATH
<richb> rfm: sneaky!
<rfm> then make sure the dlopen uses NULL for the path name (so the 
      RUN_PATH gets used)
<rfm> then the dlopen will find it if and only if the platform supports 
      the instruction set you need
<rfm> this even solves the problem of multiple machines using the same install
<richb> rfm: yes. very nice. thanks.
<rfm> Oops, dlopen with NULL may not work exactly as I wanted.  You might 
      have to set up a filter after all (make libatomic.so be a filter 
      naming $ISALIST/libultrasparc.so.1 as AUXILIARY.)  
<rfm> Ah, here's the right thing:  just dlopen("libatomic.so", ...) don't 
      use dlopen(NULL,)
<richb> okay. noted. thanks.

Comment 1

[Rich Burridge]

Adding Chris to the interest list as he's a build/config wizard.

Comment 2

[Wan-Teh Chang]

Rich:

A shared installation can be done as follows.

1. Install libultrasparc4.so in /$PKGROOT/lib.
2. Create subdirectory /$PKGROOT/lib/sun4u.
3. Add a symbolic link /$PKGROOT/lib/sun4u/libatomic.so,
   which points to ../libultrasparc4.so.
4. In the mozilla shell script, do 'uname -m' and add
   /$PKGROOT/lib/sun4u to LD_LIBRARY_PATH if the result
   is "sun4u".

Comment 3

[Rich Burridge]

Thanks wtc, we'll give this a try! If possible, can we keep the bug 
open until we get a chance to report back?

Comment 4

[hacker formerly known as [e-mail]]

Is this still an issue?

Comment 5

[Wan-Teh Chang]

*** Bug 183822 has been marked as a duplicate of this bug. ***

Comment 6

[Wan-Teh Chang]

I made two changes to NSPR's libultrasparc4.so
recently.  These changes will be in Mozilla 1.3 beta.
This means comment #2 (and similar instructions in
ug 183822 comment #5) will only apply to Mozilla
releases up to 1.3 alpha.

The two changes are:

1. libultrasparc4.so was renamed libnspr_flt4.so.

2. libnspr_flt4.so must be installed as
"cpu/sparcv8plus/libnspr_flt4.so", relative to
libnspr4.so.  That is, if libnspr4.so is installed
in directory <x>, libnspr_flt4.so should be installed
in directory <x>/cpu/sparcv8plus.  No changes to
the mozilla startup shell script are necessary.

I am not familiar with Mozilla's build tree structure,
distribution packaging, and installer, so Chris, could
you please come up with the necessary changes for NSPR
and Mozilla?

Comment 7

[Donnie Cranford]

Is this only on the Sun C compiler (Sun One Studio now) or does this work for
gcc as well?

Comment 8

[Wan-Teh Chang]

This is a linker feature and is independent of the
compiler.

Comment 9

[Roland Mainz]

wtc:
Dumb question:
What happens with your patch if someone compiles Mozilla as 64bit (=sparcv9)
application ? Will that hack/feature then be disabled automagically ?

Comment 10

[Wan-Teh Chang]

Roland,

libnspr_flt4.so is only used in the 32-bit SPARC build.
It is not used in the x86 or 64-bit SPARC build.

Comment 11

[hacker formerly known as [e-mail]]

Attachment: Put lib under $(dist_bindir) as well.

Is it natural for every sparc platform combination to be tested when it tries
to load this lib?  I thought that it was going to use $ISALIST or whatever to
single it to one path.

sysinfo(514, "sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8
sparcv8-fsmul
d sparcv7 sparc", 257) = 85
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9+vis/libnspr_flt4.so"

, 0xFFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9/libnspr_flt4.so",
0x
FFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8plus+vis/libnspr_flt4

.so", 0xFFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/nsprpub/pr/src/md/unix/libnspr_flt4.so4.so"

, "/builds/cltbld/src/mozilla/nsprpub/pr/src/md/unix/libnspr_flt4.so", 1023) =
65
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8/libnspr_flt4.so",
0x
FFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8-fsmuld/libnspr_flt4.

so", 0xFFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv7/libnspr_flt4.so",
0x
FFBEED20, 1023) Err#2 ENOENT
resolvepath("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparc/libnspr_flt4.so",
0xFF
BEED20, 1023) Err#2 ENOENT
open("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9+vis/libnspr_flt4.so",
O_RDO
NLY) Err#2 ENOENT
open("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv9/libnspr_flt4.so",
O_RDONLY)
 Err#2 ENOENT
open("/builds/cltbld/src/mozilla/dist/bin/./cpu/sparcv8plus+vis/libnspr_flt4.so",
O
_RDONLY) Err#2 ENOENT
open("/builds/cltbld/src/mozilla/nsprpub/pr/src/md/unix/libnspr_flt4.so",
O_RDONLY)
 = 3
fstat(3, 0xFFBEF094)		    = 0

Comment 12

[Wan-Teh Chang]

Chris,

It will try the paths as specified by $ISALIST one by one
to look for the "filtee".  Because our filtee (libnspr_flt4.so)
is built with the -z endfiltee linker flag, it causes the search
to stop once it is found.

This is shown in the system call trace you provided.  open() was
not invoked on "sparcv8 sparcv8-fsmuld sparcv7 sparc" because the
open for "sparcv8plus" (with relative paths and symbolic links
resolved) succeeded.  However, the call trace did show that
resolvepath() was invoked on all the paths in $ISALIST.

What still needs to be done is to make sure that libnspr_flt4.so
gets packaged and installed on Solaris.  It seems that all we
need to do is to add "bin/cpu/sparcv8plus/libnspr_flt4.so" to
mozilla/xpinstall/packager/packages-unix, correct?

Comment 13

[hacker formerly known as [e-mail]]

Attachment: Update packages-unix

I forgot about the installer packages.	I was concentrating on the fact that
Sun was using the tarballs per
http://bugzilla.mozilla.org/show_bug.cgi?id=183822#c2 .

Comment 14

[Wan-Teh Chang]

Comment on attachment 111894 [details] [diff] [review]
Put lib under $(dist_bindir) as well.

r=wtc.

Comment 15

[Wan-Teh Chang]

Comment on attachment 111961 [details] [diff] [review]
Update packages-unix

r=wtc.	Thanks!

Comment 16

[Wan-Teh Chang]

Comment on attachment 111894 [details] [diff] [review]
Put lib under $(dist_bindir) as well.

I checked in this patch on the NSPR trunk and
NSPRPUB_PRE_4_2_CLIENT_BRANCH.

Comment 17

[hacker formerly known as [e-mail]]

Attachment 111961 [details] [diff] has been checked in.