240775 - RSA operations take 2x as long with gcc build as they do with VACPP build ; assembler code isn't in use

Status: RESOLVED DUPLICATE of bug 241081

(NSS :: Libraries, defect, P2)

Description

[Julien Pierre]

I did a test with 2048 bit private key ops on my Athlon 2800.

The result with VACPP was :

[e:\dev\nss\vactip\mozilla\dist\os22.45_icc_opt.obj\bin]rsaperf -d . -s -n Julie
n Pierre's Thawte ID #3 -i 10000
10000 iterations in 36.870 seconds

And with gcc :

[e:\dev\nss\tip\mozilla\dist\os22.45_gcc_dbg.obj\bin]rsaperf -d . -s -n Julien P
ierre's Thawte ID #3 -i 10000
10000 iterations in 2 minutes, and 3.980 seconds
one operation every 12398 microseconds

ie. the gcc build takes 4 times as long.

I think this is probably due to the fact that the gcc build isn't using the x86
assembly code RSA in mozilla/security/nss/lib/freebl . A couple of years ago, I
made patches to NSS to use the assembly code. This was in the VAC build only,
since gcc wasn't in use yet.

I think when NSS was ported to gcc on OS/2, you reverted to using the C
implementation of RSA. gcc isn't particularly good at optimizations, and the
assembly code is much faster. You or may not be able to use the exact same
assembly file as used by the VAC build for the gcc build.

The VAC build uses mpi_x86.asm - the same source file as used on Windows with
MASM, but on OS/2 it gets built with IBM's MASM-compatible ALP assembler.

There is also mpi_x86.s, which is the same assembly code, but written to compile
with the GNU assembler (it's called gas, I think).
You might be able to use either one of those sources on OS/2. It's probably just
a build issue.

Comment 1

[Julien Pierre]

Woops, I posted the OPT numbers for VACPP and DBG for gcc. Not fair.

Here are the gcc OPT results.

[e:\dev\nss\tip\mozilla\dist\os22.45_gcc_opt.obj\bin]rsaperf -d . -s -n "Julien
Pierre's Thawte ID #3" -i 10000
10000 iterations in 1 minutes, and 9.930 seconds
one operation every 6993 microseconds

Still takes twice as long as VACPP opt. Changing title.

Comment 2

[Julien Pierre]

Taking bug.

Comment 3

[Julien Pierre]

Attachment: Use mpi assembly code in gcc OS/2 build, assembles with alp

This patch changes the defines to use ALP for both gcc and VACPP compilers on
OS/2, instead of only OS/2.

The rules are also changed so that the correct ALP syntax is used on OS/2 for
assembling regardless of the C compiler in use.

Finally, the Makefile for lib/freebl was changed to always use the assembly
code on OS/2, regardless of the compiler.

I chose to use the MASM-syntax mpi_x86.asm code, rather than mpi_x86.s .
I have tested it and it works fine.

With this patch, the performance of the gcc OPT build in my test is

[e:\dev\nss\tip\mozilla\dist\os22.45_gcc_opt.obj\bin]rsaperf -d . -s -n "Julien

Pierre's Thawte ID #3" -i 10000
10000 iterations in 37.220 seconds
one operation every 3722 microseconds

ie. basically the same as with the VACPP code; which makes sense since it's
mostly assembly code being called.

Comment 4

[Julien Pierre]

In the comment above, "instead of only OS/2" should have read "instead of only
VACPP".

I have tested my patch with the VACPP build also, and it didn't break it and
still used the assembly code.

Comment 5

[jhp (no longer active)]

Why did you change to using ALP for GCC? Why not just get mpi_x86.s to build for
GCC?  Perhaps you could add the following to security/nss/lib/freebl/Makefile:

  ifdef XP_OS2_EMX
     ASFILES  = mpi_x86.s
     DEFINES += -DMP_ASSEMBLY_MULTIPLY -DMP_ASSEMBLY_SQUARE -DMP_ASSEMBLY_DIV_2DX1D
  endif

Comment 6

[Wan-Teh Chang]

Comment on attachment 146339 [details] [diff] [review]
Use mpi assembly code in gcc OS/2 build, assembles with alp

r=wtc.	You guys need to decide whether
you want to use ALP as the assembler for
NSS GCC build.

> # Override suffix in suffix.mk
> LIB_SUFFIX  = lib
> DLL_SUFFIX  = dll
> PROG_SUFFIX = .exe
> 
>+# assembler settings
>+ASM_SUFFIX  = .asm
>+AS = alp.exe
>+ifdef BUILD_OPT
>+ASFLAGS = -Od
>+else
>+ASFLAGS = +Od
>+endif

It may look nicer to move ASM_SUFFIX = .asm
to the previous section (Override suffix in
suffix.mk).

>+ASFLAGS += -Feo:.o
> CCC			= gcc
> LINK			= gcc
> AR                      = emxomfar r $@

It looks nicer to use tabs after "ASFLAGS"
to align "+=" with the "=" in the next line.

Comment 7

[Mike Kaply [:mkaply]]

You can't use ALP for the GCC build, period.

It would require the OS/2 toolkit.

Comment 8

[Julien Pierre]

Mike,

I thought ALP was widely available on a fairly flexible license, but if using it
isn't acceptable for the gcc build, it should hopefully be possible to use
another assembler and use the .s files instead. The only concern I have is
whether those .s files (which are usually written for other operating systems,
such as Linux) use a calling convention supported by gcc OS/2. As long as that's
the case, there should be no problem. However, we know that ALP works today with
the the .asm source files from freebl/mpi .

Comment 9

[Julien Pierre]

Javier,

I created the patch to use ALP because there were no rules to use anything else
on OS/2 in the NSS coreconf build. If I apply only your patch, "gmake all" in
lib/freebl produces the following error

gcc -o OS22.45_gcc_DBG.OBJ/mpi_x86.o  -Wall -W -Wno-unused -Wpointer-arith -Wcas
t-align -Zomf -DDEBUG -DTRACING -g -DXP_PC=1  -DXP_OS2=1 -DSHLIB_SUFFIX=\"dll\"
-DSHLIB_PREFIX=\"\" -DRIJNDAEL_INCLUDE_TABLES -Uunix -U__unix -U__unix__ -DTCPV4
0HDRS -DDEBUG -D_DEBUG -DDEBUGPRINTS      -DXP_OS2 -DMP_ASSEMBLY_MULTIPLY -DMP_A
SSEMBLY_SQUARE -DMP_ASSEMBLY_DIV_2DX1D -DMP_USE_UINT_DIGIT -DMP_NO_MP_WORD -DMP_
API_COMPATIBLE -I../../../../dist/OS22.45_gcc_DBG.OBJ/include  -I../../../../dis
t/public/nss -I../../../../dist/private/nss -Impi -Iecl  -c mpi/mpi_x86.s
mpi/mpi_x86.s: Assembler messages:
mpi/mpi_x86.s:344: Error: unknown pseudo-op: `.section'
mpi/mpi_x86.s:345: Error: unknown pseudo-op: `.previous'
gmake.exe: *** [OS22.45_gcc_DBG.OBJ/mpi_x86.o] Error 1

In other words, it tried to assemble the mpi_x86.s assembly code with gcc.

If you know the proper syntax for gas, please contribute a patch to
mozilla/security/coreconf/OS2.mk . Are you already using gas successfully with
.s files in NSPR in the gcc build by any chance ? If so there is a good chance
the calling conventions in mpi_x86.s are compatible with gcc OS/2.

Comment 10

[Mike Kaply [:mkaply]]

> I thought ALP was widely available on a fairly flexible license

I couldn't find a single place on the web where this can be downloaded except
with a userid and password from the OS/2 shareware BBS.

Incidentally, we do .s files on OS/2 in NSPR.

See:

http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/os2/Makefile.in

Comment 11

[Julien Pierre]

Attachment: A patch that does not use alp

The good news is, the calling convention is the same between the code in the .s
and .asm files.

The bad news are :

1) the last two lines in mpi_x86.s prevent that file from assembling

2) gcc prefixes the function names with underscores, but mpi_x86.s does not.
This results in link errors

Both problems are quite easy to fix, but I believe they require yet another
copy of the mpi_x86 assembly code, in a .s file of its own specifically for
OS/2, unless we can use #ifdef in .s files, but there is no precedent for doing
that.

This patch includes Javier's changes. mpi_x86.s builds with gcc .

I present the changes to mpi_x86.s as diffs, but before check-in, they would
really have to go to a separate mpi_x86_os2_emx.s file, and the Makefile would
reference that new file in the XP_OS2_EMX section .

BTW, the rsaperf test seems to always be 1024 bits. It doesn't seem to matter
if the private key object I use has 2048 bits.

I have verified that the above patch using the .s file solves the performance
issue.

Comment 12

[jhp (no longer active)]

Actually, check out
http://lxr.mozilla.org/mozilla/source/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp
for use of #ifdefs in an assembly file.  Also, take a look at SYMBOL_UNDERSCORE,
which is defined for a platform by the #ifdef in xptc_gcc_x86_unix.h.  We use
this code on OS/2.

Comment 13

[jhp (no longer active)]

From GCC for OS/2 dev:  The problem (without looking at the file) is simply that
GCC & Binutils on OS/2 uses a.out (for historical reasons) while it on Linux
have been using ELF for close to a decade now.  In the a.out object/binary
format one is restricted to 3 predefined segments. In ELF you can define your
own segments or sections as they are called there.

Comment 14

[Wan-Teh Chang]

Comment on attachment 146509 [details] [diff] [review]
A patch that does not use alp

>  # Magic indicating no need for an executable stack
>-.section .note.GNU-stack, "", @progbits
>-.previous
>+

The comment should be deleted along with the assembler
directives.

Comment 15

[tenthumbs]

xptcinvoke_gcc_x86_unix.cpp isn't a good example because it's C++ with
embedded assembler not the straight assembler you have here. (It's also poorly
thought out. ) You should be able to use "gcc -x assembler-with-cpp" on it and
use the usual preprocessor tricks. I've seen things like:

#ifdef (LEADING_UNDERSCORE)
#define ASM_SYMBOL(foo) _ ##foo
#else
#define ASM_SYMBOL(foo) foo
#endif

Comment 16

[Julien Pierre]

Tenthumbs, is that going to work cross-platform ?
What other platforms are using the .s files ?

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Julien, Please test the patch attached to bug 241081, and tell me if the 
resultant .s file (with that patch applied) satisifes OS/2's needs, or
whether other changes (e.g. to deal with leading underscores) are also
needed for OS/2.

If one .s source file can satisfy multiple platforms without lots of ifdefs
and macros, that's good.  OTOH, if we have to add tons of macros and ifdef's
to make the code work on another platform, I'd rather just add yet-another 
source file of the asm code.  I think simple clarity of asm source is 
preferable to mere compactness (especially when there's so little).

Comment 18

[Julien Pierre]

Nelson,

Currently, OS/2 still needs the leading underscores. So, the patch in bug 241081
won't be sufficient.

I would hope that it would be possible to tell gcc OS/2 not to prepend the
underscore when referring to the external asm code, but so far I haven't found
of a way to do that.

Perhaps the gcc experts, Mike and Javier, know of one ?

I would prefer to avoid having yet another copy of this x86 asm code just for
gcc OS/2 . Adding macros to the mpi_x86.s file doesn't seem like a clean option,
though.

Comment 19

[jhp (no longer active)]

Attachment: patch

This patch links for me.  Julien, can you test this out?

Comment 20

[Julien Pierre]

Javier,

I tested it, but your patch does not link for me.

g++  -Zomf -Zdll -o OS22.45_gcc_DBG.OBJ/softokn3.dll
OS22.45_gcc_DBG.OBJ/softokn.def -o OS22.45_gcc_DBG.OBJ/softokn3.dll
OS22.45_gcc_DBG.OBJ/alghmac.o OS22.45_gcc_DBG.OBJ/dbinit.o
OS22.45_gcc_DBG.OBJ/dbmshim.o OS22.45_gcc_DBG.OBJ/ecdecode.o
OS22.45_gcc_DBG.OBJ/fipstest.o OS22.45_gcc_DBG.OBJ/fipstokn.o
OS22.45_gcc_DBG.OBJ/keydb.o OS22.45_gcc_DBG.OBJ/lowcert.o
OS22.45_gcc_DBG.OBJ/lowkey.o OS22.45_gcc_DBG.OBJ/lowpbe.o
OS22.45_gcc_DBG.OBJ/padbuf.o OS22.45_gcc_DBG.OBJ/pcertdb.o
OS22.45_gcc_DBG.OBJ/pk11db.o OS22.45_gcc_DBG.OBJ/pkcs11.o
OS22.45_gcc_DBG.OBJ/pkcs11c.o OS22.45_gcc_DBG.OBJ/pkcs11u.o
OS22.45_gcc_DBG.OBJ/rawhash.o OS22.45_gcc_DBG.OBJ/rsawrapr.o
OS22.45_gcc_DBG.OBJ/softkver.o OS22.45_gcc_DBG.OBJ/tlsprf.o  
../../../../dist/OS22.45_gcc_DBG.OBJ/lib/freebl.lib
../../../../dist/OS22.45_gcc_DBG.OBJ/lib/secutil.lib
../../../../dist/OS22.45_gcc_DBG.OBJ/lib/dbm.lib 
-L../../../../dist/OS22.45_gcc_DBG.OBJ/lib/ -lplc4 -lplds4 -lnspr4 
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_sqr_add_prop'.
weakld: info: The symbol is referenced by:
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_div_2dx1d'.
weakld: info: The symbol is referenced by:
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_mul_d'.
weakld: info: The symbol is referenced by:
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_mul_d_add_prop'.
weakld: info: The symbol is referenced by:
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_mul_d_add'.
weakld: info: The symbol is referenced by:
   
..\..\..\..\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
Ignoring unresolved externals reported from weak prelinker.

F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_sqr_add_prop" : unresolved external
F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_mul_d_add_prop" : unresolved external
F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
: error LNK2029: "_s_mpv_mul_d_add_prop" : unresolved external
F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_mul_d" : unresolved external
F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
: error LNK2029: "_s_mpv_mul_d" : unresolved external
F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_div_2dx1d" : unresolved external
F:\tip\mozilla\dist\OS22.45_gcc_DBG.OBJ\lib\freebl.lib(F:\tip\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_mul_d_add" : unresolved external


There were 7 errors detected
make.exe[2]: *** [OS22.45_gcc_DBG.OBJ/softokn3.dll] Error 1
make.exe[2]: Leaving directory `F:/tip/mozilla/security/nss/lib/softoken'
make.exe[1]: *** [libs] Error 2
make.exe[1]: Leaving directory `F:/tip/mozilla/security/nss/lib'
gmake.exe: *** [libs] Error 2

Please note that I'm building NSS standalone, not as part of the browser, by
doing "gmake nss_build_all" in mozilla/security/nss . That should make any
difference WRT this underscore problem, however.

Are you sure your patch was complete ? Did you mean to include some additional
rule changes or changes to the C code ? It seems that would be required if you
don't prepend underscores to the symbol names in the .s file  .

Also, I have been trying to build the full browser with gcc without the OS/2
toolkit . It turns out that's not possible ! The OS/2 toolkit is required.
That's because many required OS/2 headers are not part of the gcc distribution.
Is there any plan in the future for that to change ?

If not, I think we should use my original patch - the one that uses ALP and the
.asm file .

Comment 21

[jhp (no longer active)]

Yes, the OS/2 toolkit is a requirement for building.

Could you please try building the patch as part of the browser?  I made the
changes in the patch, then went to mozilla\objdbg\security\manager, 'make
clean', followed by 'make', and it built.

Comment 22

[Julien Pierre]

I will try tonight, since I have the browser working now, but I see no reason
why it would be different. I think more likely your "make clean" rule in mozilla
isn't doing the right thing for mpi, which is a subdirectory of
mozilla/security/nss/lib/freebl . So you are still linking with the old object
files and that's why it succeeds. Please check if you actually have an mpi_x86.o
. And see if it's getting linked to softokn3.dll .

To force a relink in case the rule is wrong, try manually to delete all the
mpi*.obj files in your tree, as well as mpi*.lib if you have one anywhere, and
softokn*.dll and .lib  . Then rerun the build and see if it can link. I doubt it
will.

Comment 23

[Julien Pierre]

Javier,

Here is te result of the build of a brand new tree with your patch applied . As
I exepcted, it does not link.

Given the toolkit requirement, I think we should take my initial alp patch which
has already been reviewed by Wan-Teh in this bug.

g++  -Zomf -Zdll -o G:/browser/172/mozilla/objdbg/nss/softokn/softokn3.dll
G:/browser/172/mozilla/objdbg/nss/softokn/softokn.def -o
G:/browser/172/mozilla/objdbg/nss/softokn/softokn3.dll
G:/browser/172/mozilla/objdbg/nss/softokn/alghmac.o
G:/browser/172/mozilla/objdbg/nss/softokn/dbinit.o
G:/browser/172/mozilla/objdbg/nss/softokn/dbmshim.o
G:/browser/172/mozilla/objdbg/nss/softokn/ecdecode.o
G:/browser/172/mozilla/objdbg/nss/softokn/fipstest.o
G:/browser/172/mozilla/objdbg/nss/softokn/fipstokn.o
G:/browser/172/mozilla/objdbg/nss/softokn/keydb.o
G:/browser/172/mozilla/objdbg/nss/softokn/lowcert.o
G:/browser/172/mozilla/objdbg/nss/softokn/lowkey.o
G:/browser/172/mozilla/objdbg/nss/softokn/lowpbe.o
G:/browser/172/mozilla/objdbg/nss/softokn/padbuf.o
G:/browser/172/mozilla/objdbg/nss/softokn/pcertdb.o
G:/browser/172/mozilla/objdbg/nss/softokn/pk11db.o
G:/browser/172/mozilla/objdbg/nss/softokn/pkcs11.o
G:/browser/172/mozilla/objdbg/nss/softokn/pkcs11c.o
G:/browser/172/mozilla/objdbg/nss/softokn/pkcs11u.o
G:/browser/172/mozilla/objdbg/nss/softokn/rawhash.o
G:/browser/172/mozilla/objdbg/nss/softokn/rsawrapr.o
G:/browser/172/mozilla/objdbg/nss/softokn/softkver.o
G:/browser/172/mozilla/objdbg/nss/softokn/tlsprf.o  
G:/browser/172/mozilla/objdbg/dist/lib/freebl.lib
G:/browser/172/mozilla/objdbg/dist/lib/secutil.lib
G:/browser/172/mozilla/objdbg/dist/lib/dbm.lib 
-LG:/browser/172/mozilla/objdbg/dist/lib/ -lplc4 -lplds4 -lnspr4 
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_sqr_add_prop'.
weakld: info: The symbol is referenced by:
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_div_2dx1d'.
weakld: info: The symbol is referenced by:
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_mul_d'.
weakld: info: The symbol is referenced by:
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_mul_d_add_prop'.
weakld: info: The symbol is referenced by:
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
weakld: error: Unresolved symbol (UNDEF) '_s_mpv_mul_d_add'.
weakld: info: The symbol is referenced by:
   
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
Ignoring unresolved externals reported from weak prelinker.

G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_sqr_add_prop" : unresolved external
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_mul_d_add_prop" : unresolved external
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
: error LNK2029: "_s_mpv_mul_d_add_prop" : unresolved external
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_mul_d" : unresolved external
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpmontg.c)
: error LNK2029: "_s_mpv_mul_d" : unresolved external
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_div_2dx1d" : unresolved external
G:\browser\172\mozilla\objdbg\dist\lib\freebl.lib(G:\browser\172\mozilla\security\nss\lib\freebl\mpi\mpi.c)
: error LNK2029: "_s_mpv_mul_d_add" : unresolved external


There were 7 errors detected
make.exe[5]: *** [G:/browser/172/mozilla/objdbg/nss/softokn/softokn3.dll] Error 1
make.exe[5]: Leaving directory `G:/browser/172/mozilla/security/nss/lib/softoken'
make.exe[4]: *** [libs] Error 2
make.exe[4]: Leaving directory `G:/browser/172/mozilla/security/nss/lib'
make.exe[3]: *** [libs] Error 2
make.exe[3]: Leaving directory `G:/browser/172/mozilla/objdbg/security/manager'
make.exe[2]: *** [tier_40] Error 2
make.exe[2]: Leaving directory `G:/browser/172/mozilla/objdbg'
make.exe[1]: *** [default] Error 2
make.exe[1]: Leaving directory `G:/browser/172/mozilla/objdbg'
gmake.exe: *** [build] Error 2

Comment 24

[jhp (no longer active)]

I still don't understand how this is compiling on Linux but not on OS/2.  Both
are using GCC and AS, so the conventions should be identical.

Comment 25

[Julien Pierre]

Javier,

The calling conventions are the same, but the symbol naming conventions are not.
The .o files generated by gcc OS/2 prepend an underscore for the external
symbols, but the .o files generated by as for OS/2 do not. That's why you get
the link errors. If you can find a keyword to stop gcc OS/2 from prepending
underscores for the external symbols, it will solve this problem. However, I
suggest that you take the alp patch instead, since it's already known to work
and reviewed.

Comment 26

[jhp (no longer active)]

Attachment: patch v1.1

OK, OK, OK, try this.

Comment 27

[jhp (no longer active)]

Attachment: patch v1.2

Forgot some defines.

Comment 28

[Julien Pierre]

Comment on attachment 147180 [details] [diff] [review]
patch v1.2

This patch works.

Comment 29

[Julien Pierre]

mpi_x86.s is being cleaned up in bug 241081 . Adding dependency.

Comment 30

[Fernando Cassia]

For whoever it was who complained that ALP was only available password-protected
from the OS2BBS...

If it helps, I have uploaded IBM ALP and all related files (including MASM2ALP)
taken from the OS2BBS to the Hobbes incoming directory (for final placement in
/dev/asm).

http://hobbes.nmsu.edu

Also, if someone has the ~1996 OS/2 Devcon CDs, I bet there are probably newer
versions than this (this one is dated 1995 in OS2BBS).

Hope it helps someone. And remember to upload these hard-to-find obscure tools,
code samples and everything else that might be of help to os/2 programmers to
Hobbes, as we can't keep counting that the OS2BBS (or IBM's sites) are going to
be around forever. :)

Thanks for listening, and now we return to our scheduled programming... ;)

Comment 31

[Mike Kaply [:mkaply]]

We should be moving to use the common GCC assembly.

Dupe.

*** This bug has been marked as a duplicate of 241081 ***