SpiderMonkey not multilib

NEW
Unassigned

Status

()

7 years ago
4 years ago

People

(Reporter: bkabrda, Unassigned)

Tracking

12 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:t])

(Reporter)

Description

7 years ago
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [js:t]
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.
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.
Duplicate of this bug: 572313
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.