759253 - SpiderMonkey not multilib

Status: RESOLVED INACTIVE

(Core :: JavaScript Engine, defect)

Description

[Bohuslav "Slavek" Kabrda]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120424151728

Steps to reproduce:

Compiling on x86_64 and i686 yields different file /usr/include/js/js-config.h.


Actual results:

Diff output:

--- /usr/include/js/js-config.h on x86_64	2012-05-25 14:58:49.000000000 -0400
+++ /usr/include/js/js-config.h on i686	2012-05-25 14:58:58.000000000 -0400
@@ -82,7 +82,7 @@
 /* #undef JS_INT32_TYPE */
 /* #undef JS_INT64_TYPE */
 /* #undef JS_INTPTR_TYPE */
-#define JS_BYTES_PER_WORD 8
+#define JS_BYTES_PER_WORD 4
 
 /* Some mozilla code uses JS-friend APIs that depend on JS_TRACER and
    JS_METHODJIT being correct. */


Expected results:

The file should be named differently or have the same content on both arches.

Comment 1

[David Mandelin [:dmandelin]]

Multilib isn't a Tier 1 architecture, so we can't prioritizing multilib-izing SpiderMonkey. If you happened to feel like putting together a reasonable patch, we could take it.

Comment 2

[Jeff Walden [:Waldo]]

I tend to think we should remove JS_BYTES_PER_WORD and have a static const size_t mozilla::BytesPerPointer = sizeof(void*); in mfbt/CPU.h.  This would require a little work to make fly, because we use JS_BYTES_PER_WORD in preprocessor contexts currently.  This can be worked around, and it just needs some C++ templatizing love, of the sort some of the mfbt hashing stuff does:

http://hg.mozilla.org/mozilla-central/annotate/4e3362864fbd/mfbt/HashFunctions.h#l117

It's trickier than using the preprocessor, certainly.

None of this would be backportable to Firefox 12 or whatever; it'd all have to happen on trunk.  But it's the right way to solve this, I think.  It doesn't strike me as particularly hard, just requires a little facility with templates, or a willingness to learn from how HashFunctions.h does it, and fixing up the existing users.

Comment 3

[Jeff Walden [:Waldo]]

Er, oops, that second paragraph was cut off.  Tack on "But it's a bit nicer in most other ways, including for debugging." or something like that.