Установить 64-битные программы на 32-битной ОС с 64-битным процессором

8

Мне любопытно. Можно ли установить 64-разрядную программу на 32-разрядную ОС с 64-разрядным процессором?

Я использую Linux на Raspberry Pi 3 и пытаюсь установить более новую версию MongoDB:

armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian

— crellee
источник

1

Попробуйте вместо этого использовать 64-битную ОС. Распбиан отстает от времени; 64-битная Fedora уже доступна для RPi3 .

— Майкл Хэмптон

19

Можно ли установить 64-разрядную программу на 32-разрядную ОС с 64-разрядным процессором?

В принципе да, но процессор и ОС должны его поддерживать.

В ARMv8 32-битное (Aarch32) ядро не может запускать 64-битные (Aarch64) процессы. Это ограничение процессора.

Есть другие процессоры, которые не имеют этого ограничения, например, можно запускать процессы x86_64 поверх ядра x86_32 на процессоре x86_64, но немногие ядра поддерживают его, предположительно, потому что он имеет ограниченную полезность (в основном, вы сохраняете немного оперативной памяти в ядре, сделав его 32-битным). Linux не поддерживает это, но Solaris поддерживает.

Вы можете сохранить существующую 32-битную ОС, если вы используете 64-битное ядро . Ядро Linux Aarch64 может запускать процессы Aarch32. Raspbian не поддерживает это из коробки, поэтому вам нужно поддерживать как 32-битную, так и 64-битную ОС. Вы можете использовать одну из них в качестве основной ОС (то есть ту, которая запускает init и системные службы), а другую - для запуска определенной программы с использованием chroot. Смотрите Как мне запускать 32-битные программы на 64-битном Debian / Ubuntu? для практического подхода.

Обратите внимание, что вам нужно будет установить все библиотеки, которые требуются для 64-битной программы. Любой данный процесс должен быть либо полностью 32-разрядным, либо полностью 64-разрядным, поэтому нельзя использовать 32-разрядную библиотеку в 64-разрядном исполняемом файле.

Если у вас нет веских причин сохранить 32-разрядную систему, если вам нужно запустить 64-разрядный исполняемый файл, установить 64-разрядную систему будет проще.

Обратите внимание, что единственное, что могут делать 64-битные программы, а 32-битные программы - это адрес более 3 ГБ виртуальной памяти, что имеет ограниченную полезность в системе с 1 ГБ ОЗУ. Вы можете получить выигрыш в производительности от дополнительных, более крупных регистров, но вы также потеряете производительность из-за дополнительных обращений к памяти.

— Жиль "ТАК - перестань быть злым"
источник

3

@Wildcard В двух словах, в любой момент времени либо процессор находится в 32-битном режиме («состояние выполнения Aarch32») и ожидает инструкции Aarch32, либо в 64-битном режиме ожидает инструкции Aarch64. Единственный способ переключения режимов - это переключение между процессом и ядром (или ядром и гипервизором, или гипервизором и монитором). Переключение в режим с более низкими привилегиями не может переключаться с 32-разрядного на 64-разрядный режим, а переключение в режим с более высокими привилегиями всегда восстанавливает предыдущий режим. Поэтому невозможно договориться о том, чтобы 32-битный код работал с более высокими привилегиями, чем 64-битный код.

— Жиль "ТАК - перестань быть злым"

2

@Wildcard (продолжение) Предположительно, причиной этого ограничения является то, что существует довольно много специфичного для Aarch64 состояния процессора и что код Aarch32 не может получить к нему доступ. Например, ядро Aarch32 не сможет сохранить регистры процесса Aarch64.

— Жиль "ТАК - перестань быть злым"

2

@crellee, Жиль: Вам не нужно смотреть на экзотические ОС, чтобы найти примеры 32-битных ядер с 64-битными пользовательскими областями. Чрезвычайно популярные ядра Mac OS X 10.4 "Tiger", 10.5 "Leopard" и 10.6 "Snow Leopard" поставляются в конфигурации K32 почти для всех компьютеров Mac, за исключением нескольких серверных машин, которым разрешено загружать Snow Leopard K64 , но все они были способны запускать 64-битные пользовательские процессы (с постепенно уменьшающимися ограничениями).

— Iwillnotexist Idonotexist

3

@Serge: То, что вы описываете, верно для 286 -> 386: вы можете использовать 32-битный размер операнда в 16-битном реальном режиме с префиксами, где размер операнда по умолчанию равен 16. Но Intel даже не разработала x86-64; это была AMD (именно поэтому она до сих пор иногда называется AMD64). И нет, вы вообще не можете использовать 64-битный размер операнда в 32-битном режиме. Префиксы REX переназначают однобайтовые inc/ decрегистрируют коды операций ( 0x40 .. 0x4F). В длинном режиме (64-разрядный режим) размер операнда по умолчанию равен 32, но размер адреса по умолчанию равен 64.

— Питер Кордес

2

@Wildcard: IDK, если проектное ядро вообще находилось в ядре в режиме Compat / в длинном режиме. Чтобы сохранить целочисленное состояние регистра для переключателей контекста, Solaris (и OS X) должен по-прежнему находиться в длинном режиме для доступа к r8-r15 и верхним половинам rax-rsi. IDK if xsave/ xrstorin compat mode может также сохранить полное векторное состояние. Так что это, конечно, не очень хорошо поддерживается или явно обслуживается. Вероятно, точки входа в ядро работают в 64-битном (длинном) режиме и переключаются в 32-битный (компат) режим, прежде чем переходить к остальной части ядра. (Переключатель режима x86 просто принимает far jmpи не влияет на регистры.)

— Питер Кордес

5

На некоторых архитектурах да. Но не на ARM или x86.

Вы можете использовать QEMU для эмуляции 64-битной системы, но не хотите.

— Игнасио Васкес-Абрамс
источник

Будет ли катастрофой использовать эмулятор, такой как QEMU, для установки и запуска базы данных mongo?

— Crellee

Это было бы очень, очень медленно. И не стоит, так как RPi3 имеет только 1 ГБ оперативной памяти. Вместо этого рассмотрите возможность создания 32-битного пакета.

— Игнасио Васкес-Абрамс

2

Вы можете запустить 64-битную программу поверх 32-битного ядра на x86, если ядро это поддерживает. Linux нет, но Solaris делает. На руку это не возможно.

— Жиль "ТАК - перестань быть злым"

@ IgnacioVazquez-Abrams Попробуйте это. Это медленно, но не катастрофически. Основная причина в том, что qemu делает эмуляцию процессора только в пользовательском пространстве, вызовы ядра (т.е. время ожидания) остаются прежними. В домашних системах я предпочитаю использовать бинарные файлы arm или mips для некоторых инструментов, просто для удовольствия :-) Или, иногда, если загрузка процессора не очень велика, некоторые критически важные для безопасности, но не интенсивные инструменты могут использовать некоторые экзотическая архитектура, чтобы уменьшить вероятность атак переполнения буфера.

— Петер - Восстановить Монику

4

Обновите только ваше ядро до 64-битного, чтобы вы могли запускать 64-битные двоичные файлы. По сути, он будет запускать весь ваш дистрибутив в режиме 32-битного сжатия, и ваш единственный 64-битный mongodb будет работать в обычном режиме.

Но это не заслуживает своей цены. Лучше переключить ваш mongodb на 32 бит. Однако в этом случае есть ограничение, что ваша база данных не может быть больше, чем 2 ГБ, так как она напрямую отображает всю вещь в виртуальной памяти. Если ваша база данных больше, остается только обновление ядра. (Спасибо @duskwuff расширение!)

Кстати, если ваша база данных не хочет очень большой нагрузки или вы можете использовать какое-то решение для кэширования перед этим (например, другое, но 32-битное монго), тогда эмуляция процессора может работать. Для этого начните поиск в Google для «qemu qemu-system-x86_64». Хотя такое решение, вероятно, будет иметь непосильную потребность в работе, и его можно будет считать странным в продуктивной среде.

На вашем месте я бы использовал 32-битный монго, если этого достаточно для моей базы данных, или 64-битное ядро, если его нет.

— Петер - Восстановить Монику
источник

Имеет смысл, но как бы вы переключили свой mongodb на 32 бита?

— Crellee

@crellee apt-get install mongodb:i386или что-то подобное?

— Петер - Восстановить Монику

это приведет к ошибке «Не удается найти пакет mongodb: i386»

— Crellee

1

Запуск 32-битной MongoDB - плохая идея. База данных отображена в памяти, поэтому ее запуск в 32-разрядной системе ограничивает объем данных <2 ГБ.

— duskwuff -неактив-

Да, и вы ограничены версией: 2.4.14, которая имеет множество ограничений.

— Crellee

3

Я бы сказал, что это не невозможно, но очень сложно управлять. Так как 32-битная ОС обычно поставляется с 32-битными двоичными файлами и библиотеками (и принимает их), вам нужно сильно настроить систему, чтобы она работала с 64-битными.

Основная проблема, с которой вы столкнетесь с RPI3, - это отсутствие 64-битного ядра (по крайней мере, с raspbian).

Короче говоря: используйте 32-битные двоичные файлы, и все будет в порядке.

РЕДАКТИРОВАТЬ :

Если вы хотите использовать 64-битное ядро, вам нужно установить дистрибутив, поддерживающий архитектуру ARM64. Вы должны взглянуть на ArchLinux ARM ( здесь ), но он не полностью поддерживается.

Информация, которую вы ищете, находится внизу вкладки установки.

Вы также можете взглянуть на официальный порт Debian , однако все еще есть большие проблемы с портом RPI3, так что вам решать, стоит ли эта проблема

Проблема в том, что процессор запускается (ядром) в 32-битном режиме, поэтому он выглядит как старая 32-битная машина. 64-битные регистры и инструкции недоступны.

— Йохан Мирен

1

Правильно, поэтому вам нужно 64-битное ядро (о чем говорил Томас).

— Стивен Китт

Спасибо за приятное объяснение. Таким образом, решение для меня было бы установить другую операционную систему на моем RPI3?

— Crellee

Я только что обновил свой ответ.

@Thomas, некоторые дистрибутивы поддерживают комбинированные 32- / 64-битные операции, начиная с 32-битного варианта. Debian является одним из примеров, по крайней мере, для x86: вы можете установить i386вариант, который включает в себя 64-битное ядро, которое позволяет также устанавливать 64-битные библиотеки и двоичные файлы. Однако поддержка ARM в Debian не допускает этого в системах ARM (но вы можете установить комбинированный arm64и armhf, если вы начнете с arm64).

— Стивен Китт

1

Я довольно долго использовал 64-битное ядро с 32-битной системой (это минимальная предпосылка для собственного запуска 64-битных исполняемых файлов плюс все необходимые 64-битные библиотеки). Я бы не рекомендовал это. В конечном итоге я перешел на оптовую продажу 64-битных систем, когда осознал, что заголовки ALSA, особенно в отношении вызовов Midi ioctl, не зависят от размера, а это означает, что компоненты, скомпилированные в 32-битном режиме, не будут хорошо взаимодействовать с 64-битным ядром.

Конечно, это можно считать ошибкой, которую стоит исправить, но темпы развития ALSA практически заморожены, и я не мог ждать несколько лет, пока поддержка смешанной платформы не будет исправлена (и не совместима с двоичными данными, а не смешана). исполняемые файлы), когда интерес к смешанным платформам все равно быстро падает.

Для некоторых приложений все работает в смешанном режиме (на самом деле удивительно много), но если вы делаете больше, чем просто основную часть взаимодействия с ядром, даже через внешние библиотеки, это просто чрезмерно оптимистично.