Installa i programmi a 64 bit su un sistema operativo a 32 bit con un processore a 64 bit


8

Sono curioso. È possibile installare un programma a 64 bit su un sistema operativo a 32 bit con un processore a 64 bit?

Sto eseguendo Linux su un raspberry pi 3 e provo a installare una versione più recente di 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

1
Prendi invece in considerazione l'utilizzo di un sistema operativo a 64 bit. Raspbian è molto indietro rispetto ai tempi; 64-bit Fedora è già disponibile per RPi3 .
Michael Hampton,

Risposte:


19

È possibile installare un programma a 64 bit su un sistema operativo a 32 bit con un processore a 64 bit?

In linea di principio sì, ma il processore e il sistema operativo devono supportarlo.

Su ARMv8, un kernel a 32 bit (Aarch32) non può eseguire processi a 64 bit (Aarch64). Questa è una limitazione del processore.

Esistono altri processori che non hanno questa limitazione, ad esempio è possibile eseguire processi x86_64 su un kernel x86_32 su un processore x86_64, ma pochi kernel lo supportano, presumibilmente perché è di utilità limitata (principalmente, si salva un bit di RAM nel kernel rendendolo a 32 bit). Linux non lo supporta, ma Solaris lo supporta.

Puoi mantenere il tuo sistema operativo a 32 bit esistente se esegui un kernel a 64 bit . Un kernel Linux Aarch64 può eseguire processi Aarch32. Raspbian non lo supporta immediatamente, quindi è necessario mantenere sia un sistema operativo a 32 bit sia un sistema operativo a 64 bit. È possibile utilizzare uno come sistema operativo principale (ovvero quello che esegue init e i servizi di sistema) e l'altro per eseguire un programma specifico utilizzando chroot. Vedi Come posso eseguire programmi a 32 bit su Debian / Ubuntu a 64 bit? per un approccio pratico.

Si noti che sarà necessario installare tutte le librerie richieste dal programma a 64 bit. Ogni dato processo deve essere interamente a 32 bit o interamente a 64 bit, quindi non è possibile utilizzare una libreria a 32 bit in un eseguibile a 64 bit.

A meno che non si abbiano validi motivi per mantenere un sistema a 32 bit, se è necessario eseguire un eseguibile a 64 bit, sarebbe più semplice installare un sistema a 64 bit.

Si noti che l'unica cosa che i programmi a 64 bit possono fare ma i programmi a 32 bit non possono fare è indirizzare più di circa 3 GB di memoria virtuale, che è di utilità limitata su un sistema con 1 GB di RAM. È possibile ottenere vantaggi prestazionali dai registri extra più grandi, ma si perderanno anche le prestazioni dagli accessi extra alla memoria.


3
@Wildcard In breve, in qualsiasi momento, il processore è in modalità 32-bit ("stato di esecuzione Aarch32") e si aspetta istruzioni Aarch32 o in modalità 64-bit in attesa delle istruzioni Aarch64. L'unico modo per cambiare modalità è quello di alternare tra processo e kernel (o kernel e hypervisor, oppure hypervisor e monitor). Il passaggio a una modalità con privilegi inferiori non può passare da 32 a 64 bit e il passaggio a una modalità con privilegi superiori ripristina sempre la modalità precedente. Quindi è impossibile disporre di un codice a 32 bit in esecuzione con un privilegio superiore rispetto al codice a 64 bit.
Gilles 'SO- smetti di essere malvagio' l'

2
@Wildcard (cont.) Presumibilmente il motivo di questa restrizione è che c'è un bel po 'di stato del processore specifico per Aarch64 e che il codice Aarch32 non può accedere. Ad esempio un kernel Aarch32 non sarebbe in grado di salvare i registri di un processo Aarch64.
Gilles 'SO- smetti di essere malvagio' l'

2
@crellee, Gilles: non è necessario guardare sistemi operativi esotici per trovare esempi di kernel a 32 bit con aree utente a 64 bit. I kernel estremamente popolari di Mac OS X 10.4 "Tiger", 10.5 "Leopard" e 10.6 "Snow Leopard" sono stati spediti nella configurazione K32 per quasi tutti i Mac, ad eccezione di alcuni computer server a cui era consentito avviare Snow Leopard's K64 , ma tutti erano in grado di eseguire processi userland a 64 bit (con progressivamente minori restrizioni).
Iwillnotexist Idonotexist,

3
@Serge: Quello che descrivi è vero per 286 -> 386: puoi usare la dimensione dell'operando a 32 bit in modalità reale a 16 bit con prefissi, dove la dimensione dell'operando predefinita è 16. Ma Intel non ha nemmeno sviluppato x86-64; quello era AMD (motivo per cui a volte viene ancora chiamato AMD64). E no, non è possibile utilizzare le dimensioni dell'operando a 64 bit in modalità a 32 bit. I prefissi REX riutilizzano i codici operativi a un byte inc/ decregistro ( 0x40 .. 0x4F). Nella modalità lunga (modalità 64 bit), la dimensione dell'operando predefinita è 32, ma la dimensione dell'indirizzo predefinito è 64.
Peter Cordes,

2
@Wildcard: IDK se lo spazio utente kernel / modalità lunga compat-mode era una considerazione progettuale. Per salvare lo stato del registro intero per gli switch di contesto, Solaris (e OS X) deve essere ancora in modalità lunga per accedere a r8-r15 e alle metà superiori di rax-rsi. IDK if xsave/ xrstorin modalità compatibile può salvare lo stato vettoriale completo. Quindi non è certamente ben supportato o esplicitamente soddisfatto. Probabilmente i punti di ingresso del kernel funzionano in modalità 64-bit (long) e passano alla modalità 32-bit (compat) prima di passare al resto del kernel. (Il selettore di modalità x86 richiede solo a far jmpe non influisce su regs.)
Peter Cordes,

5

Su alcune architetture, sì. Ma non su ARM o x86.

È possibile utilizzare QEMU per emulare un sistema a 64 bit, ma non si desidera.


Sarebbe un disastro usare un emulatore come QEMU per installare ed eseguire un database mongo?
Crellee,

Sarebbe molto, molto lento. E non ne vale la pena, poiché l'RPi3 ha solo 1 GB di RAM. Prendi invece in considerazione la creazione di un pacchetto a 32 bit.
Ignacio Vazquez-Abrams,

2
È possibile eseguire un programma a 64 bit su un kernel a 32 bit su x86 se il kernel lo supporta. Linux no, ma Solaris lo fa. Sul braccio non è possibile.
Gilles 'SO- smetti di essere malvagio' l'

@ IgnacioVazquez-Abrams Prova questo. È lento, ma non catastrofico. Il motivo principale è che qemu emula CPU solo nello spazio utente, le chiamate del kernel (cioè i tempi di attesa io) rimangono invariate. Sui sistemi domestici, mi piace usare i binari arm o mips per alcuni strumenti, solo per divertimento :-) O, a volte, se non c'è un carico di CPU molto grande, alcuni strumenti critici per la sicurezza, ma non ad alta intensità di CPU potrebbero usare alcuni architettura esotica, per ridurre la probabilità di attacchi di sovraccarico del buffer.
Peter - Ripristina Monica il

4

Aggiorna solo il tuo kernel a uno a 64 bit, così sarai in grado di eseguire binari a 64 bit. In sostanza, eseguirà l'intera distribuzione in modalità compatibilità a 32 bit e il tuo solo mongodb a 64 bit sarà la sua modalità normale.

Ma non merita il suo prezzo. Meglio cambiare il tuo mongodb a 32 bit. Tuttavia, in questo caso c'è una limitazione, che il tuo database non può essere più grande di 2 GB, poiché mappa direttamente l'intero oggetto nella memoria virtuale. Se il tuo db è più grande, rimane solo l'aggiornamento del kernel. (Grazie a @duskwuff l'estensione!)

A proposito, se il tuo db non vuole un carico molto grande, o puoi usare qualche soluzione di memorizzazione nella cache prima (per esempio: un altro, ma 32 bit mongo), allora un'emulazione della CPU potrebbe funzionare. Per questo, inizia a cercare su Google "qemu qemu-system-x86_64". Sebbene tale soluzione avrebbe probabilmente bisogno di un lavoro impossibile e potrebbe essere considerata strana in un ambiente produttivo.

Al posto tuo, userei mongo a 32 bit se è abbastanza per il mio db, o un kernel a 64 bit se non lo è.


Ha senso, ma come cambieresti il ​​tuo mongodb a 32 bit?
Crellee,

@crellee apt-get install mongodb:i386o qualcosa di simile?
Peter - Ripristina Monica l'

che restituirà un errore 'Impossibile trovare il pacchetto mongodb: i386'
crellee,

1
Eseguire un MongoDB a 32 bit non è una buona idea. Il database è mappato in memoria, quindi eseguirlo su un sistema a 32 bit ti limita a <2 GB di dati.
duskwuff -inattivo-

Sì, e sei limitato alla versione: 2.4.14, che presenta molte limitazioni.
Crellee,

3

Direi che non è impossibile ma davvero difficile da gestire. Poiché un sistema operativo a 32 bit in genere è compresso con (e accetta) solo binari e librerie a 32 bit, è necessario modificare fortemente il sistema per farlo funzionare con quelli a 64 bit.

Il problema principale che dovresti affrontare con un RPI3 è la mancanza di kernel a 64 bit (almeno con raspbian).

Per farla breve: usa i binari a 32 bit e starai bene.

MODIFICARE :

Se si desidera utilizzare un kernel a 64 bit, è necessario installare una distribuzione che supporti l'architettura ARM64. Dovresti dare un'occhiata ad ArchLinux ARM ( qui ), ma non è completamente supportato.

Le informazioni che stai cercando si trovano nella parte inferiore della scheda di installazione.

Puoi anche dare un'occhiata a una porta debian ufficiale , tuttavia ci sono ancora grossi problemi con la porta RPI3, quindi spetta a te decidere se vale la pena


Il problema è che la CPU viene avviata (dal kernel) in modalità 32 bit, quindi sembra una vecchia macchina a 32 bit. I registri e le istruzioni a 64 bit non sono disponibili.
Johan Myréen,

1
Bene, ecco perché avresti bisogno di un kernel a 64 bit (che Thomas ha menzionato).
Stephen Kitt,

Grazie per la bella spiegazione. Quindi la soluzione per me sarebbe installare un altro sistema operativo sul mio RPI3?
Crellee,

Ho appena aggiornato la mia risposta.

@Thomas, alcune distro supportano il funzionamento combinato a 32/64 bit, a partire dalla variante a 32 bit. Debian è un esempio, almeno su x86: è possibile installare la i386variante e include un kernel a 64 bit, che consente anche l'installazione di librerie e binari a 64 bit. Il supporto ARM in Debian non lo consente però sui sistemi ARM (ma è possibile installare in combinazione arm64e armhf, se si inizia con arm64).
Stephen Kitt,

1

Ho usato un kernel a 64 bit con un sistema a 32 bit per un po 'di tempo (questo è il prerequisito minimo per l'esecuzione nativa di eseguibili a 64 bit, oltre a tutte le librerie a 64 bit richieste). Non lo raccomanderei. Ciò che alla fine mi ha fatto passare a un sistema all'ingrosso a 64 bit è stata la consapevolezza che le intestazioni ALSA, in particolare per quanto riguarda le chiamate Midi ioctl, non erano agnostiche in termini di dimensioni, il che significa che le cose compilate in modalità 32 bit non avrebbero interagito bene con il kernel a 64 bit.

Ovviamente questo può essere considerato un bug che vale la pena correggere, ma il ritmo dello sviluppo di ALSA è quasi congelato e non vedevo l'ora per qualche anno che il supporto della piattaforma mista venisse riparato (e in modo non binario compatibile per i non-miscelati eseguibili) quando l'interesse per le piattaforme miste sta comunque diminuendo rapidamente.

Per alcune applicazioni le cose funzionano in modalità mista (sorprendentemente molto in realtà), ma se stai facendo qualcosa di più della semplice condivisione dell'interfaccia con il kernel, anche tramite librerie esterne, è semplicemente troppo ottimistico.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.