firefox扩展，在32位和/或64位firefox(版本25.0.1）上使用js-cypes

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

本文关键字：firefox js-cypes 版本 扩展 32位 64位      更新时间：2023-10-20

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

我已经掌握了扩展的基本知识，但现在我需要通过js-ctypes机制调用libcog.so共享库中的函数，有几个问题尚不清楚。

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

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

当我在/usr/lib32目录中放入一个32位的libcog.so库，但在/usr/lib目录中没有libcog.so库时，错误控制台会报告"找不到libcog.so"。

当我在/usr/lib目录中放入一个64位libcog.so库，但在/usr/lib32目录中没有放入libcog.so库时，错误控制台不会报告"找不到libcog.so"。

我认为这意味着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:js ctypes在32位浏览器的firefox扩展中总是会调用/usr/lib32（或其他32位库目录）中的32位共享库中的函数？

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

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

js-ctypes实际上只是dlopen/LoadLibrary和dlsym/GetProcAddress之上的抽象。

  • 64位浏览器中的javascript是以32位模式运行还是以64位模式运行

现在，在Firefox中，64位安装将只使用64位进程。在未来的版本中，64位Firefox可能会创建32位的子进程，从而嵌入32位的js引擎，但这是不可能的。

  • 这个问题对于像js这样的解释语言来说有意义吗

嗯，总的来说不是。Javascript是为了抽象比特甚至处理器架构而设计的。但是，当涉及到js ctypes时，这可能很重要，因为js ctype的目标是摆脱抽象和js VM/引擎的相关限制。

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

js ctypes适用于32位和64位，也适用于ARM等非x86 CPU。例如，最新版本的Firefox（以及其他支持mozilla-powered的应用程序）附带的OS.File API在内部使用js-ctypes，并且在x86和ARM（好吧，ARM上的*nix）中都受支持。

然而，当js-cypes工作时，与之接口的二进制文件当然需要是特定于平台的，并且您需要在js-cype中正确定义它们的API（以及在某种程度上扩展的ABI）。

  • 如果是，函数协议是否应始终指定为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-cypes将始终调用/usr/lib（或其他64位库目录）中64位共享库中的函数

这取决于系统动态链接器（及其配置）。大多数32位操作系统甚至没有/usr/lib32目录。x86_64可能有一个32位的用户区，但它的位置可能因发行版而异。

/usr/lib通常包含操作系统平台和bitness的本地库。x86发行版将包含32位Intel的库、64位Intel的x86_64（AMD64）发行版、ARM发行版。。。你明白了。

对于使用js-cypes的代码来说，尝试几个库是很常见的，通常带有（有些）硬编码的路径。

例如，OS.File将尝试从几个硬编码的名称加载libc，假设链接器将自己计算库路径。然而，根据链接器和其他因素（64位操作系统上的32位Firefox），这可能仍然会失败。

在另一个例子中，在我自己的一个附加组件中，我在附加组件包中为不同平台提供二进制文件，并尝试所有这些文件，直到加载为止。这样，我就可以支持不同的平台，在本例中是Win32、Win64、大多数gcc/ELF x86*nix和大多数gcc/ELF x86_64（AMD64）*nix。当然，我必须确保我的库代码足够可移植，并且在不同的体系结构上正确构建，并为所有这些目标进行编译。

我建议您阅读共享对象/dylib/DLL库和动态链接的一般内容，因为您的问题的大部分似乎不是针对js ctypes的，而是针对库/linker/OS的。

相关文章：