Include 64-bit optimized assembly on Windows when building x64

nss.gyp

Index: nss.gyp
diff --git a/nss.gyp b/nss.gyp
index 6afdaf9413287a1acd1c3ca5d9b7b58c567d0f2d..abcd96e83d597c9886937ec594624c1fa8493834 100644
--- a/nss.gyp
+++ b/nss.gyp
@@ -537,6 +537,7 @@
         'mozilla/security/nss/lib/freebl/alghmac.h',
         'mozilla/security/nss/lib/freebl/arcfive.c',
         'mozilla/security/nss/lib/freebl/arcfour.c',
+        'mozilla/security/nss/lib/freebl/arcfour-amd64-masm.asm',
         'mozilla/security/nss/lib/freebl/blapi.h',
         'mozilla/security/nss/lib/freebl/blapii.h',
         'mozilla/security/nss/lib/freebl/blapit.h',
@@ -581,12 +582,14 @@
         'mozilla/security/nss/lib/freebl/mpi/mpi.c',
         'mozilla/security/nss/lib/freebl/mpi/mpi.h',
         'mozilla/security/nss/lib/freebl/mpi/mpi_amd64.c',
+        'mozilla/security/nss/lib/freebl/mpi/mpi_amd64_masm.asm',
         'mozilla/security/nss/lib/freebl/mpi/mpi_x86_asm.c',
         'mozilla/security/nss/lib/freebl/mpi/mplogic.c',
         'mozilla/security/nss/lib/freebl/mpi/mplogic.h',
         'mozilla/security/nss/lib/freebl/mpi/mpmontg.c',
         'mozilla/security/nss/lib/freebl/mpi/mpprime.c',
         'mozilla/security/nss/lib/freebl/mpi/mpprime.h',
+        'mozilla/security/nss/lib/freebl/mpi/mp_comba_amd64_masm.asm',
         'mozilla/security/nss/lib/freebl/mpi/mp_gf2m-priv.h',
         'mozilla/security/nss/lib/freebl/mpi/mp_gf2m.c',
         'mozilla/security/nss/lib/freebl/mpi/mp_gf2m.h',
@@ -1054,11 +1057,6 @@
             ['exclude', '^mozilla/security/nss/lib/libpkix/'],
           ],
         }],
-        ['target_arch=="ia32"', {
-          'sources/': [
-            ['exclude', 'amd64'],
-          ],
-        }],
         ['OS=="mac" or OS=="ios"', {
           'defines': [
             'XP_UNIX',
@@ -1069,10 +1067,6 @@
             'SHLIB_PREFIX=\"lib\"',
             'SOFTOKEN_LIB_NAME=\"libsoftokn3.dylib\"',
           ],
-          'sources!': [
-            'mozilla/security/nss/lib/freebl/mpi/mpi_amd64.c',
-            'mozilla/security/nss/lib/freebl/mpi/mpi_x86_asm.c',
-          ],
           'xcode_settings': {
             'conditions': [
               ['component == "shared_library"', {
@@ -1122,7 +1116,59 @@
                 'MP_USE_UINT_DIGIT',
                 'MP_NO_MP_WORD',
               ],
+            }, {
+              'sources!': [
+                'mozilla/security/nss/lib/freebl/mpi/mpi_x86_asm.c',
+              ],
             }],
+            ['target_arch=="x64"', {
+              'defines': [
+                'NSS_X86_OR_X64',
+                'NSS_USE_64',
+                'NSS_X64',
+                'WIN64',

[wtc, 2013/01/04 16:26:40]

coreconf/WIN32.mk also defines _AMD64_. It may not be used,
but it is best to match that faithfully.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/WIN32.m...

+                'MP_CHAR_STORE_SLOW',
+                'MP_ASSEMBLY_MULTIPLY',
+                'MP_IS_LITTLE_ENDIAN',

[wtc, 2013/01/04 16:26:40]

Not sure if you meant to sort these macros alphabetically or
match the order in which they're defined in the NSS makefile:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/M...

Note: I generated the macro definitions in this .gyp file
by examining the compiler command lines of an upstream NSS
build. It would be nice to repeat that for an upstream NSS
WIN64 build, but I believe it should be sufficient to just
examine coreconf/WIN32.mk and lib/freebl/Makefile.

[Ryan Sleevi, 2013/01/07 03:37:34]

To match the order
I'll confirm. I focused on lib/freebl/Makefile, and forgot to check
coreconf/WIN32.mk

[wtc, 2013/01/10 03:21:09]

These macros are defined in lib/freebl/Makefile in this
order:

  MP_CHAR_STORE_SLOW
  MP_IS_LITTLE_ENDIAN
  NSS_BEVAND_ARCFOUR
  MPI_AMD64
  MP_ASSEMBLY_MULTIPLY
  NSS_USE_COMBA

The order used in this file is not sorted (but very
close) and doesn't match the order used in
lib/freebl/Makefile.

+                'MPI_AMD64',
+                'NSS_BEVAND_ARCFOUR',
+                'NSS_USE_COMBA',
+              ],
+              'rules': [
+                {
+                  'rule_name': 'assemble',
+                  'extension': 'asm',
+                  'variables': {
+                    'output_file': '<(INTERMEDIATE_DIR)/<(RULE_INPUT_ROOT)_asm.obj'

[wtc, 2013/01/04 16:26:40]

We should not need _asm before .obj. The NSS coreconf build
system does the following:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/WIN32.m...

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/ruleset...

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/rules.m...

[Ryan Sleevi, 2013/01/07 03:37:34]

There is no need to match what NSS does here for the output file naming. This
matches how we output YASM files, to avoid name conflicts (which your examples
show NSS is doing upstream, effectively)

[wtc, 2013/01/10 03:21:09]

Names of assembly code files typically contain the processor
or instruction set architecture names, so name conflicts with
C/C++ file names should be unlikely. (NSS does have a near
conflict: mpi_amd64.c and mpi_amd64_masm.asm.) In addition,
having the source files foo.c and foo.s in the same
directory is problematic if makefiles are used.

Can we remove the "_asm" from the GYP file rule for YASM
files? I wonder if it is a solution to a non-problem.
If there is a name conflict in the Chromium source tree,
I think it is better to simply append .obj to the original
assembly file name (including the .asm extension).

+                  },
+                  'outputs': [
+                    '<(output_file)',
+                  ],
+                  'action': [
+                    'ml64.exe',
+                    '/Fo', '<(output_file)',
+                    '/c',
+                    '/Ta', '<(RULE_INPUT_PATH)',

[wtc, 2013/01/04 16:26:40]

The NSS coreconf build system passes some flags to ml64.exe:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/coreconf/WIN32.m...

Please check if we need any of those flags here.

[Ryan Sleevi, 2013/01/07 03:37:34]

Yes, it appears these flags are tied to legacy MASM behaviours. Since we're
talking 2010+ here, it's equivalent to omit the flags.

+                  ],
+                  'process_outputs_as_sources': 1,
+                },
+              ],
+            }, {
+              'sources!': [
+                'mozilla/security/nss/lib/freebl/arcfour-amd64-masm.asm',
+                'mozilla/security/nss/lib/freebl/mpi/mpi_amd64.c',
+                'mozilla/security/nss/lib/freebl/mpi/mpi_amd64_masm.asm',
+                'mozilla/security/nss/lib/freebl/mpi/mp_comba_amd64_masm.asm',
+              ],
+            }],
+          ],
+        }, {

[wtc, 2013/01/04 16:26:40]

A comment here would be useful because this "else" block is
very far from the corresponding 'OS=="win"' condition.

+          'sources!': [
+            'mozilla/security/nss/lib/freebl/arcfour-amd64-masm.asm',
+            'mozilla/security/nss/lib/freebl/mpi/mpi_x86_asm.c',
+            'mozilla/security/nss/lib/freebl/mpi/mpi_amd64.c',
+            'mozilla/security/nss/lib/freebl/mpi/mpi_amd64_masm.asm',
+            'mozilla/security/nss/lib/freebl/mpi/mp_comba_amd64_masm.asm',
           ],
         }],
         ['clang==1', {