在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机制在我的共享库（libcog.so）中调用函数。

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

我不能使firefox浏览器告诉我是否是32位或64位模式的应用程序！

后来：我想我已经知道这个firefox浏览器是一个64位的应用程序如下所示：当我在/ usr / lib32目录中放置一个32位libcog.so库，而在/ usr / lib目录下没有libcog.so库时，出现错误控制台报告libcog.so找不到。

当我把一个64位的libcog.so库放在/ usr / lib目录下，而不是libcog.so库中在/ usr / lib32目录中，错误控制台不报告libcog.so not found。

我假设这意味着firefox浏览器是一个64位的应用程序， b我不是100％肯定的。

以上所有提出的各种问题：

   -  javascript是在64位浏览器中以32位模式还是64位模式运行？ 
  - 这个问题对于像js这样的解释语言是否有意义？ 
  -  64位应用程序中的JavaScript可以调用32位库函数吗？ 
  -  js-ctypes机制是否应该在64位Firefox浏览器中工作？ 
  - 注意：图书馆迄今为止做的不多，但它确实会打电话并返回。 
  - 如果是这样，函数协议应该总是指定default_abi？ 
  - 如果是这样，当javascript调用js-ctype库函数时，是：
  - 在/ usr / lib32中的32位库中调用32位函数？ 
  - 在/ usr / lib中的32位库中调用32位函数？ 
  - 在/ usr / lib32的64位库中调用64位函数？ 
  - 在/ usr / lib的64位库中调用64位函数？ 
  - 或者是什么？ 
  

我正确地假设：

＃1：在32位浏览器的Firefox扩展中的js-ctypes总是会调用/ usr / lib32（或其他32位库目录）中的32位共享库中的函数？

＃2：在64位浏览器的Firefox扩展中的js-ctypes将总是调用/ usr / lib（或其他64位库目录）中的64位共享库中的函数？ / p>

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

解决方案

js-ctypes 真的只是一个抽象的顶部 dlopen / LoadLibrary 和 dlsym / GetProcAddress 。

• JavaScript是在64位浏览器中以32位模式或64位模式运行的吗？
  

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

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

Javascript的设计是为了将位数甚至处理器架构抽象出来。但是当涉及到js-ctypes时，它可能很重要，因为js-ctypes的目标是逃避JS VM /引擎的抽象和相关限制。

• js-ctypes机制应该在64位Firefox浏览器中工作吗？
  
  $ p js-ctypes工作对于32位和64位等，也适用于非x86 CPU（如ARM）。例如，最新版本的 OS.File API Firefox（以及其他mozilla驱动的应用程序）在内部使用了js-ctypes，并且在x86和ARM（以及ARM上的* nix）中都得到了支持。然而，当js-ctypes工作的时候，你接口的二进制文件当然需要特定于平台，你需要在js-ctypes中正确地定义他们的API（以及一些扩展的ABI）。
  
  
  
  
  
  • 如果是这样，应该总是指定函数协议default_abi？
    
    
    这取决于 ABI 图书馆实际上是使用...例如，（商业）库使用 winapi_abi 是相当普遍的，因为那是windows用于系统库的东西。在* nix上，你大多会找到 cdecl / default_abi 使用，但是库作者（例如你）仍然是免费的使用其他的东西。
    
    

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

    
    
    • 如果是这样的话，当javascript调用js-ctype库函数时，在32位库中调用32位函数/ usr /在32位浏览器的firefox扩展中，js-ctypes将总是调用32位共享库中的函数/ usr / lib32（或其他32位的共享库）在64位浏览器中的firefox扩展中的js-ctypes将总是调用64位共享库中的函数/ usr / lib（或其他64位目录）位库目录）？
      
      $ b

      这取决于在系统上动态链接器（和它的配置）。
      大多数32位操作系统甚至没有一个 / usr / lib32 目录。 x86_64可能有一个32位的用户空间，但它所在的位置可能与分发到发行版不同。
      
      

      / usr / lib 通常包含OS平台本身的库和位。 x86发行版将包含用于32位Intel的库，用于64位Intel的x86_64（AMD64）发行版，ARM distribitions ... ...你会得到这样的结果。

      通常用于使用js-ctypes来尝试一些库的代码，通常使用（有点）硬编码的路径。
      
      

      例如， OS。档案会尝试从几个硬编码的名字中加载 libc ，假设链接器将自己找出库路径。然而，根据链接器和其他因素（64位操作系统上的32位Firefox），这可能仍然会失败。另一个例子是，在我自己的一个例子中附加组件，我为附加软件包中的不同平台提供了二进制文件，只是尝试所有这些直到一个加载。这样我可以支持不同的平台，在这个例子中现在是Win32，Win64，大多数gcc / ELF x86 * nix和大多数gcc / ELF x86_64（AMD64）* nix。
      当然，我必须确保我的库代码足够便携，并且在不同的体系结构上正确构建，并实际编译所有这些目标。

      
      
      

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

      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?

      解决方案

      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.

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