Solaris/Intel/WS5.0: missing xptcinvoke_asm_x86_soalris.s




19 years ago
19 years ago


(Reporter: amarzec, Assigned: shaver)



Firefox Tracking Flags

(Not tracked)



(5 attachments)



19 years ago
xptcinvoke_asm_x86_soalris.s is missing
xptcstubs_asm_X86_solaris.s is missing
Can you just use ansi c for this functionality???
I use a sun workshop compiler 5.0 for X86 and
dont have a clue how to manipulate the program
stack as you do with gcc.
Would it not carry you a lot further in to
find a good way of producing this code in ansi C.
I applaud the cleverness of the writers on makeing this code
only were does it leave the rest of us not so bright ones.
Even if you know its slower if it at least works thats all anyone
would ask.
Thanks for your kind attention

Comment 1

19 years ago
porting issue. jband, i really hate to dump this on you, but, i'm not sure where 
else to put it.
Assignee: waterson → jband
Component: XP Miscellany → XPConnect
QA Contact: brendan → rginda

Comment 2

19 years ago
If it could be done in C then we would have _very_ happily done it that way.

Shaver is still the man for xptcall on 'nix porting issues (until he says 
otherwise). I'm also cc'ing mcafee and rogerl because I think this may have come 
up before and I have no idea what the resolution was.
Assignee: jband → shaver

Comment 3

19 years ago
Better summary.
We probably just need some makefile magic to
pull in the assembly for this compiler case.
I think egcs intel build is working.?
Summary: Solaris X86 using sun compiler cant make mozilla. → Solaris/Intel/WS5.0: missing xptcinvoke_asm_x86_soalris.s


19 years ago
Ever confirmed: true

Comment 4

19 years ago
[richb - 5/4/00]
Mozilla (M15 - the one I tried) compiles and runs happily on Solaris Intel
2.6 (the O/S I tried) when built with the Gnu compilers.

When you try to compile with Sun Workshop compilers, you will get something

"xptc_platforms_unixish_x86.h", line 85: Warning: #error "need a platform define
if using unixish x86 code".
"xptc_platforms_unixish_x86.h", line 91: Warning: #error "need to define 'this'
adjust scheme".
"xptcinvoke_unixish_x86.cpp", line 121: Error: __asm__ is not defined.
"xptcinvoke_unixish_x86.cpp", line 148: Error: Unexpected ":" found.
"xptcinvoke_unixish_x86.cpp", line 161: Warning: The variable result has not yet
been assigned a value.
2 Error(s) and 3 Warning(s) detected.

There are similar errors with the assembly code in xptcstubs_unixish_x86.cpp

"__asm__" is a gcc keyword.  For Sun's native compilers you should use "asm"
keyword instead of "__asm__".

gcc manual recommends to check __GNUC__ macro to determine if  
gcc compiler used:

#ifndef __GNUC__
#define __asm__ asm

"__volatile__" is also gcc keyword. It means the same as Sun's native compilers 

Files xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp are good 
examples of using gcc compiler's "extended asm" feature but Sun's compilers 
do not support it. These two files need to be rewritten so that they will
work with either compiler.

If common assembler cannot be written, then we will need to do the same
Makefile trickery that the SPARC assembly files need for Gnu vs SW 5.0
Actually, I think GCC accepts the underscore-less (``asm'' and ``volatile'')
variants as well, so that much at least can be shared.

I don't know enough about either GCC or SunW assembly syntax to help with
developing shared code beyond that, unfortunately.

Comment 6

19 years ago
[richb - 5/4/00]
We've got a Russian engineer attempting to build M15 (and the three other
libraries that it needs). He hopefully will be able to evaluate how hard
this is to fix. As the ways of the lizard are unknown to him at the moment
this might take a few more days. I'll update this bug when I have more info.

Comment 7

19 years ago
[richb - 5/12/00]
Looks like there is another problem in getting a Solaris Intel version working
with Sun Workshop compilers. In .../mozilla/, at line 887, there is:


and in .../mozilla/js/src/, at line 153, there is:

ASFILES     = $(notdir $(wildcard $(srcdir)/*_$(OS_ARCH).s))

Unfortunately the assembly code in lock_SunOS.s in that directory is SPARC
Can you report another bug for the js/src problem, so that it can be properly

Comment 9

19 years ago
[richb - 5/14/00]
Mike, just get bug 4575 reopened.

Comment 10

19 years ago
Created attachment 8736 [details]
.tar.gz of two modified (incomplete) assembler files for Solaris Intel platform with Sun compilers.

Comment 11

19 years ago
[richb - 5/16/00]
I (and the Russian engineer) are not going to have time to work on this again 
for a while, so I'm going to pass on what we've got. 

Note that at present, if you compile Mozilla on the Solaris Intel platform
with the Gnu compilers, everything works fine. This is an attempt to try
to get the Solaris Intel version of Mozilla to work with both the Gnu and
Sun native compilers.

The previous .tar.gz attachment contains two files:


If you look at them, you will see that there is an #if 1 around the assembler
code. According to the Russian engineer, this version of the assembly code (
as opposed to the previous Gnu specific code which is in the #else part of
the #if/#endif statement), "should" work with both compilers (Gnu and Sun).
It certainly compiles with both (I was building the M15 milestone).

When the version build with Sun Workshop 5.0 compilers is run, here is the
output (no existing ~/.mozilla directory):

jmqpc1[203] ./mozilla
.// ./mozilla-bin
Segmentation Fault - core dumped
jmqpc1[204] dbx mozilla-bin core
Reading mozilla-bin
core file header read successfully
detected a multithreaded program
t@0 (l@1) terminated by signal SEGV (no mapping at the fault address)
Current function is nsServiceManagerImpl::GetService
  306                   NS_ADDREF(service);		// Released in service manager
(dbx) where
  [1] 0xdfbe45fa(0x80631f8), at 0xdfbe45f9
=>[2] nsServiceManagerImpl::GetService(this = 0x80631f8, aClass = STRUCT, aIID =
STRUCT, result = 0x80474f4, shutdownListener = (nil)), line 306 in
  [3] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result =
0x80474f4, shutdownListener = (nil)), line 499 in "nsServiceManager.cpp"
  [4] nsGetServiceByCID::operator()(this = 0x80475b4, aIID = STRUCT,
aInstancePtr = 0x80474f4), line 43 in "nsServiceManager.cpp"
  [5] nsCOMPtr_base::assign_from_helper(this = 0x80475c4, helper = CLASS, iid =
STRUCT), line 65 in "nsCOMPtr.cpp"
  [6] nsCOMPtr<nsISoftwareUpdate>::nsCOMPtr(this = 0x80475c4, helper = CLASS),
line 527 in "nsCOMPtr.h"
  [7] main1(argc = 1, argv = 0x80476f4, splashScreen = (nil)), line 652 in
  [8] main(argc = 1, argv = 0x80476f4), line 879 in "nsAppRunner.cpp"

When I build the M15 milestone with the Gnu compilers, and with these two
new files containing the modified assembler code, and then run it, I get:
jmqpc1[152] ./mozilla
.// ./mozilla-bin
nsNativeComponentLoader: autoregistering begins.
*** Registering nsTimeBomb components (all right -- a generic module!)
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
nsUnixToolkitService: Using 'gtk' for the Widget Toolkit.
nsUnixToolkitService: Using 'gtk' for the Gfx Toolkit.
NS_SetupRegistry() MOZ_TOOLKIT=gtk,,
initialized appshell
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
DEBUG BUILDS ONLY:  we are forcing you to use the profile manager to help smoke
test it.
Profile Manager : Command Line Options : End
GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24
Segmentation Fault - core dumped

Would you believe that I've been unable to find a version of gdb compiled
for the Solaris Intel platform (for Solaris 2.6 anyway). 

There is one more thing to note about the assembly code. The Russian
engineer introduce an #ifdef for position independent code 
(#if POSITION_INDEPENDENT_CODE) which I don't believe exists. If/when this
ever works, then this might need to be propagated through the

Perhaps someone more knowledgeable in x386 assembler can take this further.

Comment 12

19 years ago
[richb - 5/18/00]
I've just found bug 16114 (filed under Windows NT, so I'd missed it), that
included yet another set of assembler code that might work for both compilers.
Something more to try.

Comment 13

19 years ago
We have a fix for this, but at the moment it's in two hacked up files
(xptcstubs_unixish_x86.cpp xptcinvoke_unixish_x86.cpp) that are Sun
compiler specific. I need to merge these changes with the existing versions
of these files.  Probably early next week...

All the kudo's should go to Bill Taylor, who works for Sun in L.A. It's
nice to know there is now one more person in the world who understands
this code. ;-)

Comment 14

19 years ago
Created attachment 10284 [details] [diff] [review]
Diffs to get the two files containing the inline Solaris Intel assembler to build/run for both Gnu and Sun native compilers.

Comment 15

19 years ago
I've just attached diffs to xptcinvoke_unixish_x86.cpp and
xptcstubs_unixish_x86.cpp that build/run with both the Gnu compiler and
the Sun Workshop 5.0 compiler (in optimized mode).

I'm being explicit about the compiler status, because I still
need to determine if the files will work correctly with debug
turned on. I'm going to try this next week. Comments from Bill Taylor
(included below) suggest that they might not work with the 5.0 compiler,
but will work with 5.1 (aka Workshop 6, aka Forte). 

"> Would you expect your asm changes to work if Mozilla was compiled with
 > debug on, or without optimization (ie. no -g and no -O)?

 My first thought was "sure".  After more thinking, I'm not confident.

 There is one tricky thing about the call to invoke_copy_to_stack().
 After it returns, we might have to explicitly set %esp.  Since
 that function is declared static, the generated code need not follow
 the standard ABI calling conventions.  And, it does NOT do so in this
 case (callee pops args).   This could be different with -g, and that
 could break.  The more I think about this, it might be difficult to
 code set %esp properly if this does vary.  This is the only problem
 I can think of might happen."

Note also that Bill dramatically simplified the invoke_count_words() and
invoke_copy_to_stack() routines in xptcinvoke_unixish_x86.cpp. I'd 
appreciate comments on this. It seems to run okay, and the code looks okay, 
but I wonder why this simplication wasn't in the original code.

Same for the switch statement near the end of the PrepareAndDispatch()
method in xptcstubs_unixish_x86.cpp

Comment 16

19 years ago
As an experiment, I decided to see what would happen if I compiled up
everything with -g. The Gnu version (v2.95.2) works fine, and as expected
from Bill Taylor's last comments, the Sun Workshop 5.0 one has problems. 
It segv's at:

t@1 (l@1) signal SEGV (no mapping at the fault address) in (unknown) at 
0xdfbe428a: __RTTI__1CpknKnsObserver_+0x066e:	imull  
Current function is nsServiceManagerImpl::GetService
  306                   NS_ADDREF(service);		// Released in service 
manager destructor
(/usr/dist/share/devpro_i386,v5.0/5.x-i386/bin/dbx) where
current thread: t@1
  [1] 0xdfbe428a(0x80631f8), at 0xdfbe4289
=>[2] nsServiceManagerImpl::GetService(this = 0x80631f8, aClass = STRUCT, aIID = 
STRUCT, result = 0x8047444, shutdownListener = (nil)), line 306 in 
  [3] nsServiceManager::GetService(aClass = STRUCT, aIID = STRUCT, result = 
0x8047444, shutdownListener = (nil)), line 499 in "nsServiceManager.cpp"
  [4] nsGetServiceByCID::operator()(this = 0x8047504, aIID = STRUCT, 
aInstancePtr = 0x8047444), line 43 in "nsServiceManager.cpp"
  [5] nsCOMPtr_base::assign_from_helper(this = 0x8047514, helper = CLASS, iid = 
STRUCT), line 65 in "nsCOMPtr.cpp"
  [6] nsCOMPtr<nsISoftwareUpdate>::nsCOMPtr(this = 0x8047514, helper = CLASS), 
line 527 in "nsCOMPtr.h"
  [7] main1(argc = 1, argv = 0x8047644, splashScreen = (nil)), line 652 in 
  [8] main(argc = 1, argv = 0x8047644), line 879 in "nsAppRunner.cpp"

This was expected, and is due to a compiler bug in the SC5.0 Intel compiler.
Here's some comments that Bill sent me earlier in the week:

"With Mike Walker's help, we have identified a C++ compiler bug.
This code was built with "-g".  The first thing to do is try "-O".
Also, it may be worth considering the use of newer/better compilers
that Workshop 5.0.  (Rich is rebuilding with -O now).

The first problem we ran into and identfied is in
A thunk within it has been called by a function in a different
shared object, namely  The thunk computes the GOT
for libxpinstall, then restores ebx with the GOT for libxpcom
prior to branching to the PLT.  That is the problem."

What I now need to do is find out if it's still a problem with -g
with the latest version of the compiler (ie SC5.1, Workshop 6, Forte).

Comment 17

19 years ago
Those diffs to xptcinvoke_unixish_x86.cpp and xptcstubs_unixish_x86.cpp
work fine with Workshop 6 on Solaris Intel (compiled with -O). I've also
successfully build the M16 source tarball on Linux (which also uses
these two files).

I'm now about to try Workshop 6 on Solaris Intel (compiled with -g).

Could somebody review the diffs please? I'd like to see if they can be
checked in this week if I can get an r= and an a=. Thanks.

Comment 18

19 years ago
The other part of this problem is the fact that is setting
NS_USE_NATIVE incorrectly for the Solaris Intel platform if the Sun native
compiler is being used. NS_USE_NATIVE  seems to only be used in
.../mozilla/js/src/ (and therefore in 
.../mozilla/js/src/Makefile when it's created).

Here's a diff that fixes that problem.

stard[305] diff -c
***	Tue Jun 20 09:18:05 2000
---	Tue Jun 20 09:18:36 2000
*** 901,909 ****
         AR_FLAGS='-o $@'
-        NS_USE_NATIVE=1
         case $OS_TEST in
             ASFLAGS='-xarch=v8plus -DULTRA_SPARC -P -L -D_ASM -D__STDC__=0 -K 
--- 901,909 ----
         AR_FLAGS='-o $@'
         case $OS_TEST in
+            NS_USE_NATIVE=1
             ASFLAGS='-xarch=v8plus -DULTRA_SPARC -P -L -D_ASM -D__STDC__=0 -K 

It will now only set NS_USE_NATIVE if we are on the sun4u Solaris platform,
(ie. SPARC platform,) and we are not using the Gnu compiler.

Comment 19

19 years ago
I tested the patch on a SunOS 5.8_x86 with Workshop/Forte 6.0; the build works 

Comment 20

19 years ago
Created attachment 10449 [details] [diff] [review]
CVS diffs to get Mozilla to build/run on the Solaris Intel platform with the native Sun compilers

Comment 21

19 years ago
I now have a set of diffs that work. They apply to four files:


This change only sets NS_USE_NATIVE=1 if we are using the native compiler
on the Solaris SPARC platform, not the Solaris Intel platform. This is
used by the Makefile in ...mozilla/js/src/ , to add the assembler file
lock_SunOS.s to the build targets. This file is SPARC assembly code so
shouldn't be used on the Solaris Intel builds.


This change forces the following two platform specific files to always
be built with -O. The assembly code in those files, when used with the
Sun native compilers on the Solaris Intel platform, will only work when
compiled optimized.


These changes now allow Mozilla to be built and run with both the Gnu
compilers and the Sun native compilers on the Solaris Intel platform. 
#ifdef __GNUC__ clauses have been added to differentiate the two cases.

This has been tested with both SC5.0 and SC5.1 (aka Workshop 6, aka Forte)
Sun compilers.

The patch has also been tested on RedHat Linux 6.1 with the Gnu compilers
to make sure Gnu support on other platforms hadn't been broken.

Comment 22

19 years ago
Patch appears to compile fine on FreeBSD 5.0 w/ autoconf 2.14 and gmake 3.79

Comment 23

19 years ago
Created attachment 10470 [details] [diff] [review]
Small adjustment to the config/build diffs as suggested by cls.

Comment 24

19 years ago
I've made a small adjustment to the diffs as suggested by cls.
It now uses:

ifndef GNU_CC

rather than:

ifneq ($(CC),gcc)

so that it still works when CC is set using a full path. Thanks cls!

Comment 25

19 years ago
Created attachment 10500 [details] [diff] [review]
Added in suggestions from mccabe and brendan

Comment 26

19 years ago
I've just added another attachment with the following refinements suggested
by mccabe and brendan:

* In xptcinvoke_unixish_x86.cpp, I've added the following XXX: comment block:

/* XXX: the following line is here (rather than as the default clause in
 *      the following switch statement) so that the Sun native compiler
 *      will generate the correct assembly code on the Solaris Intel
 *      platform. See the comments in bug #28817 for more details.

* In xptcinvoke_unixish_x86.cpp, and in xptcstubs_unixish_x86.cpp, the 
  assembler for the Sun compiler is now inside a #else if defined(__SUNPRO_CC)
  block, and there is also a #else block also with an #error directive.

I've retested these changes on Solaris Intel with SC5.0 and on RedHat 6.1
Linux with the Gnu compilers, and they build and run just fine.

Comment 27

19 years ago
Fix checked in;
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 28

19 years ago
Is that only valid for M15? I'm getting (strange) errors with the tip of the 

CC -library=iostream -o nsDirectoryIndexStream.o -c -DOSTYPE=\"SunOS5\" -DOJI  -
I../../../dist/include -I../../../include        -KPIC  -mt -O  -DNDEBUG -DTRIMM
EADSAFE=1 -DLAYERS=1  nsDirectoryIndexStream.cpp
"", line 116: Error: String/char constants may not include line separator.
** Assertion ** : 0 (/set/taz/builds/fcs0406/intel-S2/lang/cafe/resources/cdr/sr
c/ 963)
make[4]: *** [nsDirectoryIndexStream.o] Error 195
make[4]: Leaving directory `/home/doehrm/mozilla/netwerk/base/src'
make[3]: *** [install] Error 2
make[3]: Leaving directory `/home/doehrm/mozilla/netwerk/base'

[doehrm@sun8 ~/mozilla]$ uname -a
SunOS sun8 5.8 Generic i86pc i386 i86pc

Comment 29

19 years ago
doehrm, my tests were indeed done against M15 (as you well know ;-).
Please file a separate Bugzilla bug for the tip-of-the-tree build
problems you are seeing in trying to build the Solaris Intel version
with the Sun Workshop compilers. Thanks.

Comment 30

19 years ago
I actually would rather that the switch statement simplifications had not been 
made. The cases were explicily layed out as much for documentation of all the 
possible cases to handle and as example for other ports as for any other reason. 
I doubt that the code size or speed was significantly improved by the change. 
But this is no big deal.
You need to log in before you can comment on or make changes to this bug.