Question Comment OSX exécute-t-il les binaires 64 bits en s'exécutant sur un noyau 32 bits?


J'ai récemment compris que Mac OS X PEUT effectivement exécuter des applications 64 bits (x64) même si le noyau x86 est chargé. Cela m'a choqué pour la première fois.

Mais alors j'ai réalisé que c'est vraiment bizarre si le système est opérationnel sous un processeur compatible x64 ne peut pas exécuter d'applications x64, quel que soit le noyau qui gère les processus. Est-ce vraiment si difficile? Il suffit de charger une application dans la mémoire et de configurer le pointeur d’opération du processeur sur le premier octet, simple comme bonjour!

Le seul et unique obstacle à cela, comme je pouvais l'imaginer, est une sorte de "en-tête exécutable". Malheureusement, je ne suis pas très à l'aise avec l'architecture Windows et la structure binaire, donc j'ai besoin de plus d'explications ici.

De facto, la norme d’en-tête binaire de type système d’exploitation UNIX ELF a son frère ELF64, qui ici décrit) n'a pas beaucoup de différences avec ELF32, mais même si les noyaux 32 bits ne peuvent pas exécuter le code x64. Oui, ce programme est probablement lié aux bibliothèques x64 et laisse imaginer que nous les avons simplement copiés et collés dans le dossier / usr / lib64. Mais je suis sûr que cela n'aide pas, pourquoi?

Et enfin, quelle est la particularité du noyau Mac OS X pour qu'il ne se soucie pas du jeu d'instructions de programme utilisé? Mac OS X a-t-il un en-tête universel pour les exécutables des deux noyaux, de sorte qu'il peut simplement charger une application dans la mémoire et dire à CPU "d'exécuter à partir d'ici, qu'est-ce que cela signifie"?

P.S .: J'ai vraiment réfléchi à l'endroit où placer cette question: sur stackoverflow.com ou superuser.com, et j'ai décidé de placer ici, car le sujet est probablement plus spécifique à l'OS.


4
2017-09-27 20:08


origine


Qu'est-ce qui vous a fait penser que OSX exécutera un fichier binaire 64 bits sur un noyau Darwin 32 bits? Qu'as-tu vu? - James T Snell
Parce que j'étais à peu près sûr que j'utilisais le noyau x64, donc le seul logiciel que j'avais installé était le x64 et le système d'exploitation les exécutait parfaitement. Mais il y a peu de temps, j'ai tapé "uname -a" dans mon terminal et j'ai été surpris. En outre, Wikipedia confirme ceci - en.wikipedia.org/wiki/X86-64#Mac_OS_X - pechenie
Wikipedia et vous deux pouvez vous tromper. Exécuter un système d'exploitation 64 bits ne signifie pas que tous vos fichiers binaires sont 32 bits. Cela signifie que votre architecture noyau et matérielle peut prendre en charge les fichiers binaires 64 bits. Que fait votre uname-a revenir? - James T Snell
Aussi, je ne comprends pas le titre de votre question. Pouvez-vous s'il vous plaît le reformuler? - James T Snell
Ce n'est pas une erreur, vous pouvez l'essayer si vous le pouvez. J'exécutais un noyau x86, pas x64, et je pouvais toujours exécuter un logiciel x64. Je suis déjà passé à l'architecture x64_86 maintenant, mais la sortie de uname -a sous le noyau x86 était probablement quelque chose comme ça: Darwin MacMini.local 11.1.0 Darwin Kernel Version 11.1.0: Tue Jul 26 16:07:11 PDT 2011; root:xnu-1699.22.81~1/RELEASE_i386 i386 - pechenie


Réponses:


La vraie question serait de savoir pourquoi certains autres systèmes d'exploitation ne peuvent pas exécuter de fichiers binaires 64 bits sur un noyau 32 bits. Il n'y a aucune raison fondamentale pour laquelle ce ne serait pas possible. L'architecture du processeur sous-jacent prend en charge à la fois un jeu d'instructions 64 bits (amd64 aka x86-64) et un jeu d'instructions 32 bits (i386), et il n'y a pas de restriction d'utilisation conjointe (en particulier, il n'y a pas "Mode 64 bits" séparé du "mode 32 bits", il y a un seul mode long, qui permet des instructions à la fois du i386 et du jeu amd64 "natif").

Exécuter des applications 64 bits sur un noyau 32 bits nécessite un peu plus de travail au sein du noyau, car il doit gérer des pointeurs 64 bits vers l’espace utilisateur avec des pointeurs 32 bits vers l’espace noyau. La plupart, sinon tous les pointeurs transmis dans le noyau sont connus pour être dans le noyau ou connus pour être de l'espace utilisateur. Ce n'est donc pas un problème s'ils sont de taille différente. La principale difficulté consiste à renoncer à la possibilité d'avoir un type de pointeur universel avec des plages de valeurs distinctes pour la mémoire de processus, la mémoire du noyau et la mémoire utilisée par divers matériels (y compris la RAM), mais ce n'est pas possible dans les noyaux 32 bits récents de toute façon sur un matériel de classe PC (si vous avez 4 Go de RAM ou plus, ou si vous voulez mapper 2 Go de RAM plus 2 Go d'espace de traitement plus la mémoire du noyau et plus encore, vous devez pouvoir mapper plus de 32 bits d'adresses) ).

Selon le Article de Wikipedia Comme vous le citez, OSX pouvait exécuter des processus amd64 sur des processeurs amd64 avant d’avoir un noyau 64 bits. Solaris mélange également indifféremment les exécutables i386 et amd64 sur les processeurs amd64, que le noyau soit 32 bits ou 64 bits (les deux sont disponibles).

D'autres systèmes d'exploitation peuvent exécuter des processus i386 sur un noyau (64 bits) amd64, mais pas sur des processus amd64 sur un noyau 32 bits, par exemple Linux, FreeBSD, NetBSD et Windows. Pourtant, d'autres systèmes d'exploitation traitent amd64 et i386 comme des architectures complètement différentes, par exemple OpenBSD.


2
2017-09-27 21:59



Les pointeurs AIUI ne sont pas un problème dans OS X car ils ne sont de toute façon pas passés entre le noyau et l’espace utilisateur. Même avec un processus 32 bits s'exécutant sous un noyau 32 bits, le processus peut avoir jusqu'à 4 Go d'espace de mémoire virtuelle défini, et le noyau peut également avoir jusqu'à 4 Go, et les deux ne se chevauchent pas. Si vous passiez un pointeur de l'espace utilisateur au noyau, cela n'aurait aucun sens car il y a quelque chose de complètement différent à cette adresse dans l'espace noyau. - Gordon Davisson
Si vous regardez le code source, vous pouvez voir comment cela se passe. Sous OS X 32 bits, le noyau n’est pas mappé dans l’espace d’adresse des utilisateurs, de sorte qu’ils disposent tous deux d’espaces d’adresse 32 bits entièrement distincts. Toutes les données transmises sont de toute façon copiées ou remappées. La pénalité est les échecs du cache TLB. - russbishop
La question est de savoir comment le processeur peut stocker le contexte lorsque le mode 32 bits ne peut pas accéder aux registres 64 bits et 8 registres supérieurs. - phuclv
@ LưuVĩnhPhúc Vous avez besoin d'un petit bit de code 64 bits, juste pour sauvegarder et restaurer les registres. Autant que je sache, c'est possible sur x86-64 (et c'est ainsi que Solaris le fait). Ce serait en effet un problème sur le bras où vous ne pouvez pas mélanger des instructions 64 bits et 32 ​​bits sans changement de privilège. - Gilles


Je ne connais pas assez bien l'architecture x86_64 pour donner les détails, mais essentiellement, le processeur passe du mode 64 bits au mode de compatibilité (32 bits) dans le cadre du changement de contexte entre le noyau et un espace utilisateur. programme. C'est à peu près la même chose que pour exécuter un programme 32 bits sous un noyau 64 bits, ce qui se passe simplement en sens inverse.

BTW, OS X n'utilise pas le format binaire ELF, il utilise Mach-O binaires. Le format Mach-O permet des binaires multi-architectures ("universels"), donc les programmes (et le noyau) peuvent être fournis en 32 et 64 bits (et PPC et PPC64 et ...), et le système d'exploitation peut Choisissez la version à charger (et donc le mode à exécuter) au moment du chargement. Vous pouvez utiliser le file commande sur un binaire pour voir quel (s) format (s) il est (s). Par exemple, voici l'application Chess livrée avec OS X v10.5:

$ file Applications/Chess.app/Contents/MacOS/Chess 
Applications/Chess.app/Contents/MacOS/Chess: Mach-O universal binary with 4 architectures
Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc): Mach-O executable ppc
Applications/Chess.app/Contents/MacOS/Chess (for architecture ppc64):   Mach-O 64-bit executable ppc64
Applications/Chess.app/Contents/MacOS/Chess (for architecture i386):    Mach-O executable i386
Applications/Chess.app/Contents/MacOS/Chess (for architecture x86_64):  Mach-O 64-bit executable x86_64

Et une note pour ceux qui doutent que cela soit possible: OS X supportait les programmes 64 bits à partir de la version 10.4 (avec un support limité de l'API), mais n'incluait pas de noyau 64 bits avant la version 10.6 (et même alors, le le noyau a fonctionné en mode 32 bits par défaut sur la plupart des modèles). Voir Guide de transition 64 bits d'Apple pour plus de détails. J'affiche ceci à partir d'un MacBook Pro fonctionnant sous 10.6 avec un noyau 32 bits (64 bits n'est pas pris en charge pour ce modèle particulier), mais d'après Activity Monitor, le seulement Le processus ne fonctionnant pas en mode 64 bits est kernel_task.


4
2017-09-27 21:54





Les Mac prennent en charge l'exécution d'applications 64 bits sur un noyau 32 bits, car un plan à plusieurs étapes pour faire exactement cela:

  1. Les applications Mac sont livrées sous forme de "fichiers binaires" dans des "bundles" qui permettent aux quatre combos 64/32-bit et Intel / PPC de faire partie d'une seule installation, qui peut être aussi simple qu'un glisser-déposer. Le système d'exploitation exécute le bon.
  2. Les Mac utilisent PAE pour accéder à plus de 4 Go de RAM lorsqu'ils exécutent un noyau 32 bits. Windows n'autorise pas PAE sur les versions non-serveur en raison de problèmes de compatibilité avec les pilotes, dont ils ont beaucoup plus, y compris ceux de tiers.
  3. Tiger ajoute une interface ABI (Application Binary Interface) 64 bits pour exécuter du code 64 bits sur le noyau 32 bits, et une version 64 bits des API (Application Programming Interface) de bas niveau pour "console" (pas GUI) applications.
  4. Leopard ajoute Cocoa 64 bits pour les applications GUI (mais pas Carbon 64 bits).
  5. Snow Leopard ajoute un noyau 64 bits, qui est la valeur par défaut de certains modèles haut de gamme uniquement.
  6. Lion nécessite un processeur 64 bits, mais inclut toujours le noyau 32 bits. Un ancien Mac avec un processeur 64 bits mais un GPU qui ne dispose que de pilotes 32 bits devrait par exemple exécuter le noyau 32 bits.

Ainsi, OS X supportait les applications 64 bits dès que possible et continuait à exécuter le noyau 32 bits aussi longtemps que possible en raison de la situation du pilote. (Le bit-ness du noyau ne devient un facteur que lorsque vous essayez de gérer des quantités énormes de RAM - les tables de pages prennent également de la mémoire - et passer à un noyau 64 bits offre des avantages de performance.) des trucs.

La vraie question est donc de savoir pourquoi Windows et Linux n’ont pas fait la même chose. Pour Windows, considérez que leur première tentative de Win64 était avec Itanium, qui était complètement différent. Mais la réponse finale pourrait se résumer à ce qu’elle a généralement été au cours des dernières décennies: la compatibilité avec un tas de programmes tiers n'a pas fait les choses comme il faut:

L’implémentation 64 bits d’OS X est très différente de celle de   Windows, qui traite ses versions 32 bits et 64 bits comme deux versions distinctes   systèmes d'exploitation stockés sur différents supports d'installation. C'est fait   principalement pour maintenir la compatibilité de Windows avec les anciennes applications -   déplacer ou renommer des choses comme le dossier System32   programmes qui l’attendaient - et par conséquent les deux sont   séparé au point qu'il n'y a même pas un chemin de mise à niveau entre   Windows 32 bits et Windows 64 bits. À cause de cela et parce que   Les applications Windows et les pilotes ont généralement 32 bits et   Versions 64 bits, la transition de Windows vers 64 bits a été légèrement   plus rock et légèrement plus visible pour l'utilisateur.

Il y a beaucoup d'informations de base sur la transition 64 bits à la fois sur le Côté Mac et le Côté Windows. (Ces liens sont les derniers de chaque série d'articles, assurez-vous de revenir au début de chaque article.)

Je ne sais pas quelle était l'histoire avec Linux, mais imaginons que Linus avait une forte opinion à ce sujet.


3
2017-09-28 01:55



Du côté de Linux: le noyau supportait les architectures 32 bits et 64 bits bien avant l’existence de l’amd64. L'exécution de processus 64 bits sur un noyau 32 bits nécessiterait une réingénierie, du moins dans les parties du code dépendant de l'architecture. Assez a été fait pour exécuter des binaires i386 sur un noyau amd64, mais pas l'autre (plus compliqué), car il n'y a pas de cas d'utilisation vraiment motivant pour cette direction (si vous voulez exécuter des processus 64 bits, Noyau 64 bits). - Gilles
Merci beaucoup pour votre explication, je ne peux pas encore voter (pas assez de réputation), et je ne peux pas accepter deux réponses aussi, mais vous et Gilles m'ont un peu clarifié! - pechenie


Je me suis rendu compte que c'est vraiment bizarre si le système est compatible avec les processeurs x64 et que les processeurs ne peuvent pas exécuter les applications x64, quel que soit le noyau qui gère les processus. Est-ce vraiment si difficile? Il suffit de charger une application dans la mémoire et de configurer le pointeur d’opération du processeur sur le premier octet, simple comme bonjour!

Vous manquez une partie importante. Les applications effectuent des appels API aux fonctions et aux services fournis par le système d'exploitation. Si une application 64 bits envoie un pointeur 64 bits vers un système d'exploitation 32 bits, les choses devraient exploser.

Je pense que pour que les choses fonctionnent de manière acceptable dans les deux cas, le système d'exploitation doit surcharger la fonction et fournir à la fois une version 64 bits et une version 32 bits de chaque fonction. Pour chaque noyau, la fonction "off" (fonction 64 bits sur les noyaux 32 bits, fonction 32 bits sur les noyaux 64 bits) sera juste un stub qui traduira l'appel en 32 bits, puis rappellera la fonction native.


0
2017-09-28 02:03