расширение firefox с js-ctypes в 32-битной и/или 64-битной версии Firefox (версия 25.0.1)

Я создаю расширение firefox для linux firefox на 64-битной ubuntu. Расширение представляет собой программу javascript, которая вызывает функции в моей общей библиотеке (libcog.so), написанной на C, через механизм js-ctypes.

Я разобрался с основами работы расширения, но теперь, когда мне нужно вызывать функции в разделяемой библиотеке libcog.so через механизм js-ctypes, некоторые вопросы остаются неясными.

Я не могу заставить браузер Firefox сказать мне, является ли это приложение 32-битным или 64-битным режимом!

Позже: я думаю, что понял, что этот браузер Firefox является 64-битным приложением следующим образом:

Когда я помещаю 32-разрядную библиотеку libcog.so в каталог /usr/lib32, но не добавляю библиотеку libcog.so в каталог /usr/lib, консоль ошибок сообщает «libcog.so не найден».

Когда я помещаю 64-разрядную библиотеку libcog.so в каталог /usr/lib, но не библиотеку libcog.so в каталог /usr/lib32, консоль ошибок не сообщает «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 в расширении Firefox в 32-битном браузере всегда будут вызывать функции в 32-битной общей библиотеке в /usr/lib32 (или другом каталоге 32-битной библиотеки)?

# 2: js-ctypes в расширении firefox в 64-битном браузере всегда будут вызывать функции в 64-битной общей библиотеке в /usr/lib (или другом каталоге 64-битной библиотеки)?

С обычными двоичными файлами компилируемого языка многие ответы на эти вопросы довольно очевидны. А интерпретатор... Не знаю... может быть, они почти все могут подделать или имитировать?


javascript firefox firefox-addon 32bit-64bit jsctypes
person honestann    schedule 26.11.2013    source источник
comment
Как правило, микширование разрядности не может выполняться в рамках одного процесса. Если javascript запускается как отдельный процесс, это может быть что угодно, независимо от разрядности родительского процесса. Нет подделки, которая загружает 32-битный .so в 64-битный процесс.   -  person durasm    schedule 27.11.2013

Ответы (1)


arrow_upward
2
arrow_downward

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?

js-ctypes работает как для 32-битных, так и для 64-битных систем, а также для процессоров, отличных от x86, таких как ARM. Например, API OS.File, который поставляется с последней версией Firefox (и другие приложения на базе Mozilla) использует внутри себя js-ctypes и поддерживается как в x86, так и в ARM (ну, *nix на ARM).

Однако, несмотря на то, что js-ctypes работает, двоичные файлы, с которыми вы взаимодействуете, должны, конечно, быть специфичными для платформы, и вам необходимо правильно определить их API (и ABI в некоторой степени) в js-ctypes.

  • Если да, то следует ли всегда указывать протокол функции default_abi?

Это зависит от ABI. библиотека на самом деле использует... Например, для (коммерческой) библиотеки довольно часто используется winapi_abi, потому что это то, что Windows использует для системных библиотек. В *nix вы в основном найдете cdecl/default_abi использование, но автор библиотеки (например, вы) по-прежнему может использовать что-то еще.

Либо прочитайте документацию для системных и сторонних библиотек, либо при самостоятельном создании библиотеки вы уже должны знать, что используете.

  • Если да, то когда javascript вызывает функции библиотеки js-ctype, это: вызов 32-битных функций в 32-битных библиотеках в /usr/lib32? и т. д.
  • js-ctypes в расширении firefox в 32-битном браузере всегда будут вызывать функции в 32-битной общей библиотеке в /usr/lib32 (или другом каталоге 32-битной библиотеки)?
  • js-ctypes в расширении firefox в 64-битном браузере всегда будут вызывать функции в 64-битной общей библиотеке в /usr/lib (или другом каталоге 64-битной библиотеки)?

Это зависит системного динамического компоновщика (и его конфигурации). ). В большинстве 32-битных операционных систем нет даже каталога /usr/lib32. x86_64 может иметь 32-битную пользовательскую среду, но ее расположение может различаться в разных дистрибутивах.

/usr/lib обычно содержит библиотеки, родные для платформы ОС и разрядности. Дистрибутивы x86 будут содержать библиотеки для 32-разрядной версии Intel, дистрибутивы x86_64 (AMD64) для 64-разрядной версии Intel, дистрибутивы ARM... вы поняли.

Код, использующий js-ctypes, довольно часто пытается использовать пару библиотек, часто с (несколько) жестко закодированными путями.

Например, OS.File будет попытаться загрузить libc из пары жестко закодированных имен, предполагая, что компоновщик сам определит пути к библиотеке. Однако в зависимости от компоновщика и других факторов (32-разрядная версия Firefox в 64-разрядной ОС) это все же может привести к сбою.

В другом примере, в одном из моих собственных дополнений я отправляю бинарные файлы для разных платформ в пакете надстройки и просто попробуйте все, пока не загрузится один из них. Таким образом, я могу поддерживать разные платформы, в этом примере прямо сейчас Win32, Win64, большинство gcc/ELF x86 *nix и большинство gcc/ELF x86_64 (AMD64) *nix. Конечно, я должен был убедиться, что код моей библиотеки достаточно переносим, ​​корректно строится на разных архитектурах и действительно компилируется для всех этих целей.

Я бы порекомендовал вам прочитать общие библиотеки объектов/dylib/DLL и динамическое связывание в целом, потому что большая часть вашего вопроса, похоже, не относится к js-ctypes, а больше относится к библиотеке/компоновщику/ОС в целом.

person nmaier    schedule 27.11.2013
comment
Спасибо за ваши исчерпывающие ответы. Почти вся моя информация взята с веб-сайта MDN и книги Javascript для веб-разработчиков, 2-е издание (намного лучше, чем мои другие 12 книг по javascript/mozilla вместе взятых). Мне не повезло создать это расширение, начиная с нулевого знания javascript, mozilla или расширений браузера (но опытного программиста C/системы). Лучшая документация js-ctypes значительно помогла бы. Теперь у меня есть основы расширения, работающего на моем 64-битном firefox на 64-битной ubuntu, включая функции вызова в моей 64-битной библиотеке libcog.so. - person honestann; 28.11.2013
comment
Меня смущают не библиотеки object/dylib/DLL, а только то, как javascript [с js-ctypes] взаимодействует с ними во всех конфигурациях (я годами писал и создавал обычные приложения и библиотеки C/asm). В результате мой мозг совершенно привык мыслить в терминах скомпилированного (или собранного) кода и поэтому совершенно запутывается, пытаясь представить, что является обычным (или возможным) для интерпретируемых языков. Слишком многое в javascript кажется странным, неестественным и запутанным. Я не мог заставить js-ctypes загружать/вызывать мой coglib.so с путем, начинающимся с chrome:. Почему бы нет? - person honestann; 28.11.2013
comment
js-ctypes просто не поддерживает ни один протокол (даже протокол file:), а только нативные пути, потому что это то, что поддерживает базовый libffi/динамический компоновщик. js-ctypes — это просто абстракция поверх dlopen/LoadLibrary и dlsym/GetProcAddress. - person nmaier; 28.11.2013
comment
Чувак @honestann, я против тебя. У меня есть опыт работы с js, но нет C. Удалось ли вам использовать js-ctypes в Linux? Я хотел бы увидеть вашу работу. - person Blagoh; 26.08.2014
comment
@Blagoh: Да, js-ctypes отлично работает в Linux (в моем коде расширения Firefox). Я не уверен, что означает тяга, но если вы хотите увидеть какой-то код, отправьте электронное письмо на мое имя пользователя в ymail точка com, и мы сможем общаться. Вы хорошо разбираетесь в javascript? - person honestann; 28.08.2014
comment
Большое спасибо, я отправлю вам электронное письмо очень скоро. Я приличный в этом :) - person Blagoh; 28.08.2014