How to recognize 32 or 64 bit from within an extension

[Jan Honza Odvarko]

To do a little bug workaround I need to recognize whether Firefox is running in 32 or 64 bits.

I am getting following values when using:

Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime).XPCOMABI

Mac VM on Windows Vista: x86_64-gcc3
Ubuntu 9.04 VM on Windows Vista: x86-gcc3
Windows XP & Vista: x86-msvc

Is this safe way to get such information?

What values I am supposed to get on real Mac 32/64 installation and Linux 32/64 installation?

Or is there any other and better option to get the info?

Honza

[Boris Zbarsky]

On 1/26/12 12:42 PM, Jan Honza Odvarko wrote:
> To do a little bug workaround I need to recognize whether Firefox is running in 32 or 64 bits.
>
> I am getting following values when using:
>
> Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime).XPCOMABI
>
> Mac VM on Windows Vista: x86_64-gcc3
> Ubuntu 9.04 VM on Windows Vista: x86-gcc3

> Windows XP& Vista: x86-msvc

>
> Is this safe way to get such information?
>
> What values I am supposed to get on real Mac 32/64 installation and Linux 32/64 installation?

I get "x86-gcc3" in a 32-bit Mac build, and "x86_64-gcc3" in a 64-bit
Mac build.

I suspect that for your specific use case (which really cares about
32-bit GCC, not 32-bit in general), just testing for "x86-gcc3" is fine.

-Boris

[Dave Townsend]

On 01/26/12 03:42, Jan Honza Odvarko wrote:
> To do a little bug workaround I need to recognize whether Firefox is running in 32 or 64 bits.
>
> I am getting following values when using:
>
> Cc["@mozilla.org/xre/app-info;1"].getService(Ci.nsIXULRuntime).XPCOMABI
>
> Mac VM on Windows Vista: x86_64-gcc3
> Ubuntu 9.04 VM on Windows Vista: x86-gcc3

> Windows XP& Vista: x86-msvc

>
> Is this safe way to get such information?
>
> What values I am supposed to get on real Mac 32/64 installation and Linux 32/64 installation?
>
> Or is there any other and better option to get the info?

Don't think there is anything better, the ABI is
{CPU_ARCH}-{TARGET_COMPILER_ABI}, just stripping out the CPU_ARCH and
comparing it with known values you care about would work.

https://developer.mozilla.org/en/XPCOM_ABI

[David Rajchenbach-Teller]

There is a bug open for recognizing the OS from JS (recall that we
cannot use nsIXULRuntime from chrome workers). We can extend this to
incorporate information on 32-bits/64-bits.

https://bugzilla.mozilla.org/show_bug.cgi?id=709771

Cheers,
David

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform


--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[Benjamin Smedberg]

On 1/26/2012 2:24 PM, David Rajchenbach-Teller wrote:
> There is a bug open for recognizing the OS from JS (recall that we
> cannot use nsIXULRuntime from chrome workers). We can extend this to
> incorporate information on 32-bits/64-bits.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=709771

Why do you need to do this from workers? Why not do this before you
launch the worker and then tell the worker that information via a
message if that's critically important?

--BDS

[David Rajchenbach-Teller]

The problem with this kind of design is that, if a library needs to know
which on OS it is running (e.g. OS.Path), there is no way to implement
it so that it works both on the main thread and in a worker.

Cheers,
David

[Philipp Kewisch]

On a ChromeWorker you could probably use jsctypes and check the size of
a pointer. Very much a hack though and might not work as expected for
all platforms.

Philipp

[David Rajchenbach-Teller]

On Fri Jan 27 01:04:57 2012, Philipp Kewisch wrote:
> On a ChromeWorker you could probably use jsctypes and check the size
> of a pointer. Very much a hack though and might not work as expected
> for all platforms.

As a side-note, I have the impression that most uses of jsctypes,
regardless of the thread, require some OS information, to determine the
name of the library (e.g. libc vs. libc.so.6 vs. libSystem).

[Zack Weinberg]

On 2012-01-26 10:08 PM, David Rajchenbach-Teller wrote:
> On Fri Jan 27 01:04:57 2012, Philipp Kewisch wrote:
>> On a ChromeWorker you could probably use jsctypes and check the size
>> of a pointer. Very much a hack though and might not work as expected
>> for all platforms.
>
> As a side-note, I have the impression that most uses of jsctypes,
> regardless of the thread, require some OS information, to determine the
> name of the library (e.g. libc vs. libc.so.6 vs. libSystem).

We could eliminate many of those cases by providing access to
dlsym(RTLD_DEFAULT, "whatever").

zw

[Mike Hommey]

If you do, please file a dependent bug for our new linker on android to
support that.

Mike

[Dave Townsend]

On 01/26/12 22:08, David Rajchenbach-Teller wrote:
> On Fri Jan 27 01:04:57 2012, Philipp Kewisch wrote:
>> On a ChromeWorker you could probably use jsctypes and check the size
>> of a pointer. Very much a hack though and might not work as expected
>> for all platforms.
>
> As a side-note, I have the impression that most uses of jsctypes,
> regardless of the thread, require some OS information, to determine the
> name of the library (e.g. libc vs. libc.so.6 vs. libSystem).

I think ctypes.libraryName helps resolve a lot of these:
https://developer.mozilla.org/en/js-ctypes/js-ctypes_reference/ctypes#libraryName%28%29

[Mike Hommey]

It only helps with libraries with the same basename on all platforms
(like nspr), but doesn't for system libraries, which usually have
completely different names, and completely different functions, for that
matter. And making cross-platform goop with ctypes is all but fun. It's
easier to have a C/C++ layer in between.

Mike

[Dave Townsend]

True, using system libraries will require knowing about the system.