firefox extension with js-ctypes on 32-bit and/or 64-bit firefox (version 25.0.1)

Question

I am creating a firefox extension for linux firefox on 64-bit ubuntu. The extension is a javascript program that calls functions in my shared library (libcog.so) written in C via the js-ctypes mechanism.

I got the basics of the extension working, but now that I need to call functions in the libcog.so shared library via the js-ctypes mechanism, several issues are unclear.

I can't make the firefox browser tell me whether it is a 32-bit or 64-bit mode application!

Later: I think I figured out this firefox browser is a 64-bit application as follows:

When I put a 32-bit libcog.so library in the /usr/lib32 directory but no libcog.so library in the /usr/lib directory the error console reports "libcog.so not found".

When I put a 64-bit libcog.so library in the /usr/lib directory but not libcog.so library in the /usr/lib32 directory, the error console does not report "libcog.so not found".

I assume this means the firefox browser is a 64-bit application, but I'm not 100% sure.

All the above raises various questions:

- Is javascript in a 64-bit browser running in 32-bit mode or 64-bit mode?
  - Does this question even make sense for interpreted languages like js?
  - Can javascript in 64-bit applications call 32-bit library functions?
- Should the js-ctypes mechanism even work in a 64-bit firefox browser?
  - NOTE: The library does little so far, but it does call and return.
  - If so, should function protocol always be specified default_abi?
  - If so, when javascript calls js-ctype library functions, is it:
    - calling 32-bit functions in 32-bit libraries in /usr/lib32?
    - calling 32-bit functions in 32-bit libraries in /usr/lib?
    - calling 64-bit functions in 64-bit libraries in /usr/lib32?
    - calling 64-bit functions in 64-bit libraries in /usr/lib?
    - or what?

Am I correct to assume:

#1: js-ctypes in a firefox extension in a 32-bit browser will always call functions in a 32-bit shared library in /usr/lib32 (or other 32-bit library directory)?

#2: js-ctypes in a firefox extension in a 64-bit browser will always call functions in a 64-bit shared library in /usr/lib (or other 64-bit library directory)?

With regular compiled-language binaries, many of the answers to these questions are rather obvious. But an interpreter... I dunno... maybe they can fake or simulate almost anything?

Answer 1

js-ctypes really is just an abstraction on top of dlopen/LoadLibrary and dlsym/GetProcAddress.

• Is javascript in a 64-bit browser running in 32-bit mode or 64-bit mode?

Right now, in Firefox, a 64-bit installation will only use 64-bit processes. In future versions, it is possible, but unlikely, that a 64-bit Firefox may create 32-bit child processes that therefore might embed a 32-bit js engine.

• Does this question even make sense for interpreted languages like js?

Well, in general no. Javascript is designed to abstract away the bitness and even processor architecture. But when it comes to js-ctypes, it might matter, as the goal of js-ctypes is to escape the abstraction and associated limits of the JS VM/engine.

• Should the js-ctypes mechanism even work in a 64-bit firefox browser?

js-ctypes works for 32-bit and 64-bit alike, and also for non x86 CPUs such as ARM. For example, the OS.File API, which comes with recent version of Firefox (and other mozilla-powered applications) does use js-ctypes internally, and is supported in x86 and ARM (well, *nix on ARM) alike.

However, while js-ctypes work, the binaries you interface with need to be platform specific, of course, and you need to correctly define their APIs (and ABI to some extend) in js-ctypes.

• If so, should function protocol always be specified default_abi?

This depends on the ABI the library is actually using... For example, it is quite common for (commercial) library to use winapi_abi, because that is what windows uses for the system libraries. On *nix you'll mostly find cdecl/default_abi use, but a library author (e.g. you) is still free to use something else.

Either read the documentation for system and third party libraries, or when creating a library yourself, you should be already knowing what you're using.

• If so, when javascript calls js-ctype library functions, is it: calling 32-bit functions in 32-bit libraries in /usr/lib32?, etc.
• js-ctypes in a firefox extension in a 32-bit browser will always call functions in a 32-bit shared library in /usr/lib32 (or other 32-bit library directory)?
• js-ctypes in a firefox extension in a 64-bit browser will always call functions in a 64-bit shared library in /usr/lib (or other 64-bit library directory)?

This depends on the system dynamic linker (and it's configuration). Most 32-bit operating systems won't even have a /usr/lib32 directory. x86_64 might have a 32-bit userland, but where it is located might different from distribution to distribution.

/usr/lib usually contains libraries native to the OS platform and bitness. x86 distributions will contain libraries for 32-bit Intel, x86_64 (AMD64) distributions for 64-bit Intel, ARM distribitions... you get the drift.

It is quite common for code using js-ctypes to try a couple of libraries, often with (somewhat) hard-coded paths.

For example, OS.File will attempt to load libc from a couple of hard-coded names, assuming the linker will figure out the library paths itself. Depending on the linker and other factors (32-bit Firefox on 64-bit OS), this might still fail, however.

In another example, in one of my own add-ons, I ship binaries for different platforms in the add-on package and just try all of them until one loads. That way I can support different platforms, in this example right now Win32, Win64, most gcc/ELF x86 *nix and most gcc/ELF x86_64 (AMD64) *nix. Of course, I had to make sure my library code is portable enough and does build correctly on different architectures and actually compile for all these targets.

I'd recommend you read up on shared object/dylib/DLL libraries and dynamic linking in general, because most parts of your question do not seem to be specific to js-ctypes, but more to library/linker/OSes in general.