Installer des programmes 64 bits sur un système d'exploitation 32 bits avec un processeur 64 bits

8

Je suis curieux. Est-il possible d'installer un programme 64 bits sur un OS 32 bits avec un processeur 64 bits?

J'utilise Linux sur un raspberry pi 3 et j'essaie d'installer une version plus récente de 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
la source
1
Envisagez plutôt d'utiliser un système d'exploitation 64 bits. Raspbian est loin derrière les temps; Fedora 64 bits est déjà disponible pour le RPi3 .
Michael Hampton

Réponses:

19

Est-il possible d'installer un programme 64 bits sur un OS 32 bits avec un processeur 64 bits?

En principe oui, mais le processeur et l'OS doivent le supporter.

Sur ARMv8, un noyau 32 bits (Aarch32) ne peut pas exécuter des processus 64 bits (Aarch64). Il s'agit d'une limitation du processeur.

Il existe d'autres processeurs qui n'ont pas cette limitation, par exemple, il est possible d'exécuter des processus x86_64 sur un noyau x86_32 sur un processeur x86_64, mais peu de noyaux le prennent en charge, probablement parce que son utilité est limitée (la plupart du temps, vous enregistrez un peu de RAM dans le noyau en le rendant 32 bits). Linux ne le prend pas en charge, mais Solaris le fait.

Vous pouvez conserver votre système d'exploitation 32 bits existant si vous exécutez un noyau 64 bits . Un noyau Linux Aarch64 peut exécuter des processus Aarch32. Raspbian ne prend pas cela en charge, vous devez donc conserver à la fois un système d'exploitation 32 bits et un système d'exploitation 64 bits. Vous pouvez utiliser l'un comme système d'exploitation principal (c'est-à-dire celui qui exécute les services init et système) et l'autre pour exécuter un programme spécifique à l'aide de chroot. Voir Comment exécuter des programmes 32 bits sur un Debian / Ubuntu 64 bits? pour une approche pratique.

Notez que vous devrez installer toutes les bibliothèques requises par le programme 64 bits. Tout processus donné doit être entièrement en 32 bits ou entièrement en 64 bits, vous ne pouvez donc pas utiliser une bibliothèque 32 bits dans un exécutable 64 bits.

À moins d'avoir de bonnes raisons de conserver un système 32 bits, si vous devez exécuter un exécutable 64 bits, il serait plus facile d'installer un système 64 bits.

Notez que la seule chose que les programmes 64 bits peuvent faire mais que les programmes 32 bits ne peuvent pas faire est de traiter plus d'environ 3 Go de mémoire virtuelle, ce qui est d'une utilité limitée sur un système avec 1 Go de RAM. Vous pouvez obtenir des avantages en termes de performances des registres supplémentaires et plus volumineux, mais vous perdrez également les performances des accès à la mémoire supplémentaire.

Gilles 'SO- arrête d'être méchant'
la source
3
@Wildcard En résumé, à tout moment, le processeur est en mode 32 bits («état d'exécution Aarch32») et attend des instructions Aarch32, ou en mode 64 bits attend des instructions Aarch64. La seule façon de changer de mode est de basculer entre le processus et le noyau (ou le noyau et l'hyperviseur, ou l'hyperviseur et le moniteur). Le passage à un mode à privilèges inférieurs ne peut pas passer de 32 bits à 64 bits, et le passage à un mode à privilèges supérieurs restaure toujours le mode précédent. Il est donc impossible d'organiser un code 32 bits avec un privilège supérieur au code 64 bits.
Gilles 'SO- arrête d'être méchant'
2
@Wildcard (suite) La raison de cette restriction est probablement due au fait qu'il y a beaucoup d'état de processeur spécifique à Aarch64 et que le code Aarch32 n'est pas accessible. Par exemple, un noyau Aarch32 ne pourrait pas enregistrer les registres d'un processus Aarch64.
Gilles 'SO- arrête d'être méchant'
2
@crellee, Gilles: Vous n'avez pas besoin de regarder des OS exotiques pour trouver des exemples de noyaux 32 bits avec des zones d'utilisateurs 64 bits. Les noyaux Mac OS X 10.4 "Tiger", 10.5 "Leopard" et 10.6 "Snow Leopard" extrêmement populaires sont livrés dans la configuration K32 pour presque tous les Mac, à l'exception de quelques machines serveur autorisées à démarrer le K64 de Snow Leopard , mais toutes ils étaient capables d'exécuter des processus 64 bits de l'utilisateur (avec progressivement moins de restrictions).
Iwillnotexist Idonotexist
3
@Serge: Ce que vous décrivez est vrai pour 286 -> 386: vous pouvez utiliser une taille d'opérande 32 bits en mode réel 16 bits avec des préfixes, où la taille d'opérande par défaut est 16. Mais Intel n'a même pas développé x86-64; c'était AMD (c'est pourquoi on l'appelle encore parfois AMD64). Et non, vous ne pouvez pas du tout utiliser la taille d'opérande 64 bits en mode 32 bits. Les préfixes REX réutilisent les opcodes à un octet inc/ decregistre ( 0x40 .. 0x4F). En mode long (mode 64 bits), la taille d'opérande par défaut est 32, mais la taille d'adresse par défaut est 64.
Peter Cordes
2
@Wildcard: IDK si le noyau en mode compatible / l'espace utilisateur en mode long était une considération de conception. Pour enregistrer l'état du registre entier pour les commutateurs de contexte, Solaris (et OS X) doit toujours être en mode long pour accéder à r8-r15 et aux moitiés supérieures de rax-rsi. IDK si xsave/ xrstoren mode compat peut également enregistrer l'état vectoriel complet. Ce n'est donc certainement pas bien pris en charge ou explicitement pris en charge. Les points d'entrée du noyau s'exécutent probablement en mode 64 bits (long) et basculent en mode 32 bits (compat) avant de passer au reste du noyau. (Le commutateur de mode x86 prend juste un far jmpet n'affecte pas les paramètres.)
Peter Cordes
5

Sur certaines architectures, oui. Mais pas sur ARM ou x86.

Vous pouvez utiliser QEMU pour émuler un système 64 bits, mais vous ne le souhaitez pas.

Ignacio Vazquez-Abrams
la source
Serait-ce un désastre d'utiliser un émulateur comme QEMU pour installer et exécuter une base de données Mongo?
crellee
Ce serait très, très lent. Et cela n'en vaut pas la peine, car le RPi3 n'a que 1 Go de RAM. Envisagez plutôt de créer un package 32 bits.
Ignacio Vazquez-Abrams
2
Vous pouvez exécuter un programme 64 bits sur un noyau 32 bits sur x86 si le noyau le prend en charge. Linux ne le fait pas, mais Solaris le fait. Sur le bras, ce n'est pas possible.
Gilles 'SO- arrête d'être méchant'
@ IgnacioVazquez-Abrams Essayez ceci. C'est lent, mais pas catastrophique. La principale raison est que qemu ne fait d'émulation cpu que dans l'espace utilisateur, les appels du noyau (c'est-à-dire les temps d'attente io) restent les mêmes. Sur les systèmes domestiques, j'aime utiliser des binaires arm ou mips pour certains outils, juste pour le plaisir :-) Ou, parfois, s'il n'y a pas une très grande charge de processeur, certains outils critiques pour la sécurité, mais peu gourmands en processeur pourraient utiliser certains architecture exotique, pour diminuer la probabilité d'attaques par dépassement de tampon.
peterh
4

Mettez à niveau uniquement votre noyau vers un noyau 64 bits, afin de pouvoir exécuter des binaires 64 bits. Essentiellement, il exécutera toute votre distribution en mode compat 32 bits, et votre seul mongodb 64 bits sera son mode normal.

Mais il ne mérite pas son prix. Mieux vaut passer votre mongodb en 32 bits. Cependant, dans ce cas, il y a une limitation, que votre base de données ne peut pas être plus grande que 2 Go, car elle mappe directement le tout dans la mémoire virtuelle. Si votre base de données est plus grande, seule la mise à niveau du noyau reste. (Merci l'extension @duskwuff!)

Btw, si votre base de données ne veut pas une très grosse charge, ou si vous pouvez utiliser une solution de mise en cache avant elle (par exemple: une autre, mais un mongo 32 bits), alors une émulation cpu pourrait fonctionner. Pour cela, lancez une recherche sur "qemu qemu-system-x86_64". Bien qu'une telle solution aurait probablement un besoin de travail irréalisable et pourrait être considérée comme étrange dans un environnement productif.

À votre place, j'utiliserais du mongo 32 bits si c'est pour ma base de données suffisante, ou un noyau 64 bits si ce n'est pas le cas.

peterh - Réintégrer Monica
la source
C'est logique, mais comment changeriez-vous votre mongodb en 32 bits?
crellee
@crellee apt-get install mongodb:i386ou quelque chose de similaire?
peterh
qui renverra une erreur «Impossible de localiser le paquet mongodb: i386»
crellee
1
L'exécution d'un MongoDB 32 bits est une mauvaise idée. La base de données est mappée en mémoire, donc l'exécuter sur un système 32 bits vous limite à <2 Go de données.
duskwuff -inactive-
Oui, et vous êtes limité à la version: 2.4.14, qui a beaucoup de limitations.
crellee
3

Je dirais que ce n'est pas impossible mais vraiment difficile à gérer. Étant donné qu'un système d'exploitation 32 bits est généralement fourni avec (et accepte) uniquement des fichiers binaires et des bibliothèques 32 bits, vous devez modifier fortement le système pour le faire fonctionner avec des fichiers 64 bits.

Le principal problème auquel vous seriez confronté avec un RPI3 est le manque de noyau 64bits (au moins avec raspbian).

Pour faire court: utilisez des binaires 32 bits et tout ira bien.

ÉDITER :

Si vous souhaitez utiliser un noyau 64bits, vous devrez installer une distribution prenant en charge l'architecture ARM64. Vous devriez jeter un œil à ArchLinux ARM ( ici ), mais il n'est pas entièrement pris en charge.

Les informations que vous recherchez se trouvent au bas de l'onglet d'installation.

Vous pouvez également jeter un oeil à un port Debian officiel , mais il y a toujours de gros problèmes avec le port RPI3, donc c'est à vous de décider si cela en vaut la peine


la source
Le problème est que le CPU est démarré (par le noyau) en mode 32 bits, il ressemble donc à une vieille machine 32 bits. Les registres et instructions 64 bits ne sont pas disponibles.
Johan Myréen
1
C'est vrai, c'est pourquoi vous auriez besoin d'un noyau 64 bits (dont Thomas a parlé).
Stephen Kitt
Merci pour la belle explication. La solution pour moi serait donc d'installer un autre OS sur mon RPI3?
Crellee
Je viens de mettre à jour ma réponse.
@Thomas, certaines distributions prennent en charge le fonctionnement combiné 32/64 bits, à commencer par la variante 32 bits. Debian en est un exemple, au moins sur x86: vous pouvez installer la i386variante, et cela inclut un noyau 64 bits, qui permet également d'installer des bibliothèques et des binaires 64 bits. Le support ARM dans Debian ne permet pas cela sur les systèmes ARM (mais vous pouvez installer combiné arm64et armhf, si vous commencez par arm64).
Stephen Kitt
1

J'ai utilisé un noyau 64 bits avec un système 32 bits pendant un certain temps (c'est la condition minimale pour exécuter les exécutables 64 bits en natif, plus toutes les bibliothèques 64 bits requises). Je ne le recommanderais pas. Ce qui m'a finalement fait passer à un système 64 bits en gros, c'est la prise de conscience que les en-têtes ALSA, en particulier en ce qui concerne les appels Midi ioctl, n'étaient pas indépendants de la taille, ce qui signifie que les choses compilées en mode 32 bits ne fonctionneraient pas bien avec le noyau 64 bits.

Bien sûr, cela peut être considéré comme un bug à corriger, mais le rythme de développement d'ALSA est presque figé et je ne pouvais pas attendre quelques années pour que le support de la plate-forme mixte soit corrigé (et d'une manière compatible non binaire pour les non mixtes). exécutables) lorsque l'intérêt pour les plates-formes mixtes diminue de toute façon rapidement.

Pour certaines applications, les choses fonctionnent en mode mixte (étonnamment beaucoup en fait), mais si vous faites plus que le partage de base de l'interface avec le noyau, même via des bibliothèques externes, c'est juste trop optimiste.


la source