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
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.
You need to log in before you can comment on or make changes to this bug.