在 32 位和/或 64 位 firefox 上使用 js-ctypes 的 firefox 扩展(版本 25.0.1) [英] firefox extension with js-ctypes on 32-bit and/or 64-bit firefox (version 25.0.1)

问题描述

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

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.

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

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.

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

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

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

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

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

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".

当我在/usr/lib目录下放了一个64位的libcog.so库但在/usr/lib32目录下放了libcog.so库时，错误控制台没有报告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".

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

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?

我的假设是否正确:

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

#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: 64 位浏览器中 firefox 扩展中的 js-ctypes 将始终调用/usr/lib(或其他 64 位库目录)中 64 位共享库中的函数?

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

推荐答案

js-ctypes 实际上只是在 dlopen/LoadLibrary 和 dlsym/GetProcAddress.

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

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

目前，在 Firefox 中，64 位安装将仅使用 64 位进程.在未来的版本中，64 位 Firefox 可能会创建 32 位子进程，从而嵌入 32 位 js 引擎.

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.

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

嗯，一般不会.Javascript 旨在抽象掉位数甚至处理器架构.但是当谈到 js-ctypes 时，它可能很重要，因为 js-ctypes 的目标是摆脱 JS VM/引擎的抽象和相关限制.

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.

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

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

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.

然而，虽然 js-ctypes 可以工作，但您所连接的二进制文件当然需要特定于平台，并且您需要在 js-ctypes 中正确定义它们的 API(以及某种扩展的 ABI).

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.

• 如果是这样，函数协议是否应该始终指定为 default_abi?

这取决于ABI 库实际上正在使用...例如，(商业)库使用 winapi_abi 是很常见的，因为 Windows 使用的是系统库.在 *nix 上，您通常会发现 cdecl/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.

• 如果是这样，javascript调用js-ctype库函数时，是不是:调用/usr/lib32中32位库中的32位函数?等
• 32 位浏览器中 firefox 扩展中的 js-ctypes 将始终调用/usr/lib32(或其他 32 位库目录)中 32 位共享库中的函数?
• 64 位浏览器中 firefox 扩展中的 js-ctypes 将始终调用/usr/lib(或其他 64 位库目录)中 64 位共享库中的函数?

这取决于系统动态链接器(和它的配置).大多数 32 位操作系统甚至没有 /usr/lib32 目录.x86_64 可能有 32 位用户空间，但它的位置可能因发行版而异.

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 通常包含操作系统平台和位数的本机库.x86 发行版将包含适用于 32 位 Intel 的库、适用于 64 位 Intel 的 x86_64 (AMD64) 发行版、ARM 发行版……您会有所偏差.

/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.

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

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

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

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.

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

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.

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

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.

这篇关于在 32 位和/或 64 位 firefox 上使用 js-ctypes 的 firefox 扩展(版本 25.0.1)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！