javascript - 在 32 位和/或 64 位 firefox(版本 25.0.1)上使用 js-ctypes 的 firefox 扩展

Question

我正在 64 位 ubuntu 上为 linux firefox 创建一个 firefox 扩展。该扩展是一个 javascript 程序，它通过 js-ctypes 机制调用我用 C 语言编写的共享库 (libcog.so) 中的函数。

我了解了扩展工作的基础知识，但是现在我需要通过 js-ctypes 机制调用 libcog.so 共享库中的函数，有几个问题不清楚。

我无法让 firefox 浏览器告诉我它是 32 位还是 64 位模式的应用程序!

后来:我想我发现这个firefox浏览器是一个64位应用程序，如下所示:

当我将 32 位 libcog.so 库放在/usr/lib32 目录中但/usr/lib 目录中没有 libcog.so 库时，错误控制台报告“找不到 libcog.so”。

当我在/usr/lib 目录下放了一个 64 位的 libcog.so 库，但在/usr/lib32 目录下没有放 libcog.so 库时，错误控制台没有报告“libcog.so not found”。

我认为这意味着 firefox 浏览器是一个 64 位应用程序，但我不能 100% 确定。

以上都提出了各种问题:

- 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?

我是否正确假设:

#1:在 32 位浏览器的 firefox 扩展中的 js-ctypes 总是会调用/usr/lib32(或其他 32 位库目录)中的 32 位共享库中的函数？

#2:在 64 位浏览器中的 firefox 扩展中的 js-ctypes 总是会调用/usr/lib(或其他 64 位库目录)中的 64 位共享库中的函数？

使用常规的编译语言二进制文件，这些问题的许多答案都相当明显。但是翻译...我不知道...也许他们可以伪造或模拟几乎任何东西？

Answer 1

js-ctypes真的只是 dlopen 之上的抽象/ LoadLibrary 和 dlsym / GetProcAddress .

64 位浏览器中的 javascript 是在 32 位模式还是 64 位模式下运行？

目前，在 Firefox 中，64 位安装将仅使用 64 位进程。在 future 的版本中，64 位 Firefox 有可能(但不太可能)创建 32 位子进程，因此可能会嵌入 32 位 js 引擎。

这个问题对于像 js 这样的解释型语言是否有意义？

嗯，一般来说没有。 Javascript 旨在抽象出位数甚至处理器架构。但是当涉及到 js-ctypes 时，它可能很重要，因为 js-ctypes 的目标是摆脱 JS VM/引擎的抽象和相关限制。

js-ctypes 机制是否应该在 64 位 firefox 浏览器中工作？

js-ctypes 适用于 32 位和 64 位，也适用于非 x86 CPU，例如 ARM。例如，OS.File最新版本的 Firefox(和其他支持 mozilla 的应用程序)附带的 API 确实在内部使用 js-ctypes，并且在 x86 和 ARM(嗯，ARM 上的 *nix)中都受支持。

然而，当 js-ctypes 工作时，您与之交互的二进制文件当然需要特定于平台，并且您需要在 js-ctypes 中正确定义它们的 API(以及某种程度上的 ABI)。

如果是这样，是否应该始终指定函数协议(protocol) default_abi？

这取决于 ABI该库实际上正在使用...例如，(商业)库使用 winapi_abi 是很常见的。 ，因为这是 Windows 用于系统库的内容。在 *nix 上，您通常会找到 cdecl/default_abi使用，但库作者(例如您)仍然可以自由使用其他东西。

阅读系统和第三方库的文档，或者在自己创建库时，您应该已经知道自己在使用什么。

如果是，javascript调用js-ctype库函数时，是不是:在/usr/lib32中调用32位库中的32位函数？等

32 位浏览器中的 Firefox 扩展中的 js-ctypes 将始终调用/usr/lib32(或其他 32 位库目录)中的 32 位共享库中的函数？

64 位浏览器中的 firefox 扩展中的 js-ctypes 将始终调用/usr/lib(或其他 64 位库目录)中的 64 位共享库中的函数？

这取决于 on the system dynamic linker (and it's configuration) .
大多数 32 位操作系统甚至没有 /usr/lib32目录。 x86_64 可能具有 32 位用户空间，但它所在的位置可能因发行版而异。
/usr/lib通常包含操作系统平台和位数的 native 库。 x86 发行版将包含适用于 32 位 Intel 的库、适用于 64 位 Intel 的 x86_64 (AMD64) 发行版、ARM 发行版……您会明白的。

使用 js-ctypes 的代码尝试几个库是很常见的，通常使用(有些)硬编码的路径。

例如，OS.File将attempt to load libc从几个硬编码的名称中，假设链接器将自己找出库路径。但是，根据链接器和其他因素(64 位操作系统上的 32 位 Firefox)，这可能仍然会失败。

在另一个示例中，在我自己的一个附加组件中，我在附加包中为不同平台提供二进制文件，并且只是 try all of them直到一个加载。这样我就可以支持不同的平台，在这个例子中现在是 Win32、Win64、大多数 gcc/ELF x86 *nix 和大多数 gcc/ELF x86_64 (AMD64) *nix。
当然，我必须确保我的库代码具有足够的可移植性，并且确实可以在不同的架构上正确构建，并且可以针对所有这些目标进行实际编译。

我建议您阅读共享对象/dylib/DLL 库和动态链接，因为您的问题的大部分似乎并不特定于 js-ctypes，而更多的是一般的库/链接器/操作系统。