Kernel a 64 bit, ma tutti i processi eseguibili ELF a 32 bit in esecuzione, come va?

L'output di uname:

root@debian:~ # uname -a
Linux 5asnb 2.6.32-5-amd64 #1 SMP Mon Jun 13 05:49:32 UTC 2011 x86_64 GNU/Linux

Tuttavia, l' /sbin/initeseguibile si presenta come a 32 bit:

root@debian:~ # file /sbin/init
/sbin/init: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

Anche altri aspetti del sistema sembrano contraddire le cose:

root@debian:~ # echo $HOSTTYPE
i486

root@debian:~ # getconf LONG_BIT
32

— kiiwii
fonte

Il kernel a 64 bit può essere installato su Debian a 32 bit. Puoi vedere che il kernel amd64 è disponibile per Debian a 32 bit nella sua pagina del pacchetto . Questo può essere usato come alternativa all'utilizzo di un kernel abilitato PAE per supportare più di 4G di RAM totale. Si noti che i binari a 32 bit non possono ancora accedere a circa 3G di RAM per processo.

— jordanm
fonte

grazie! le tue risposte sono chiare come una sfera di cristallo ~: D Non ho mai notato che Debian tratta il pacchetto del kernel in questo modo.

— kiiwii,

Non è vero: i programmi a 32 bit possono utilizzare l'intero 4Gio del loro spazio di indirizzi virtuale quando sono in esecuzione su un kernel a 64 bit (a meno che non siano in esecuzione con la personalità ADDR_LIMIT_3GB).

— ysdx,

@ysdx Quindi limitare a 2 GB è una cosa specifica di Windows e gli indirizzi superiori a 0x80000000 saranno consentiti nello spazio utente a 32 bit?

— Paul Stelian,

@PaulStelian, Su Windows a 32 bit, per impostazione predefinita sei limitato ai più bassi 2 GB di memoria virtuale per retrocompatibilità (penso che alcuni programmi utilizzati per riservare puntatori ai più alti 2 GB di memoria virtuale per scopi speciali). È possibile impostare il flag LARGEADDRESSAWARE nel file eseguibile ( docs.microsoft.com/fr-fr/cpp/build/reference/… ) per attivare l'accesso a tutti i 4 GB di memoria virtuale.

— ysdx,

Tutti i processori che supportano il set di istruzioni x64 (noto anche come x86_64 o amd64) supportano anche il set di istruzioni x86 (noto anche come i386 o i686, che sono rigorosamente versioni specifiche di x86). Lo stesso vale per ARM A64 (il nuovo set di istruzioni a 64 bit che appare in ARMv8) e A32 (il nome per il "classico" set di istruzioni a 32 bit), per SPARC64 e SPARC , e credo per MIPS64 e MIPS . Quindi su tutte queste famiglie di architettura, se un processore può eseguire codice a 64 bit, può anche eseguire codice a 32 bit.

Il kernel Linux supporta l'esecuzione del codice userland a 32 bit con un kernel a 64 bit (credo su tutte le famiglie di architettura sopra menzionate). Il kernel deve essere omogeneo (tutti a 64 bit o tutti a 32 bit) e ogni processo deve essere omogeneo, ma è possibile disporre di una combinazione di processi a 32 e 64 bit su un kernel a 64 bit. Il contrario non è possibile: con un kernel a 32 bit, non è possibile eseguire processi a 64 bit.

Questa è una scelta progettuale in Linux, motivata dal desiderio di eseguire binari a 32 bit esistenti su installazioni a 64 bit. Altre varianti di Unix hanno fatto diverse scelte: Solaris può eseguire programmi a 64 bit su un kernel a 32 bit e viceversa, mentre OpenBSD non può eseguire programmi a 32 bit su un kernel a 64 bit.

È possibile ottenere informazioni sulla CPU in /proc/cpuinfo. Se la tua CPU x86 ha il lmflag, è una CPU a 64 bit.

Per impostazione predefinita, uname -mo archmostra l'architettura per cui è stato compilato il kernel. Linux può impostare la "personalità" di un processo (con la personality) chiamata di sistema. È possibile eseguire un sottoprocesso con una personalità diversa con il setarchcomando; setarch i686 someprogramo linux32 someprogramesegue il programma specificato in un ambiente in cui uname -mritorna i686mentre setarch amd64 someprogramo linux64 someprogramesegue il programma specificato in un ambiente in cui uname -mritorna amd64.

file /sbin/initti dice per quale architettura initè stato compilato il programma. Sebbene sia possibile combinare eseguibili a 32 e 64 bit in un'installazione, in genere tutti i principali programmi del sistema operativo provengono dalla stessa architettura, perché è molto più facile da gestire.

$HOSTYPEè una variabile bash e ti dice per quale architettura bashè stato compilato il programma.

getconf LONG_BITti consente di sapere se il compilatore C predefinito è impostato per compilare programmi a 32 o 64 bit. Un test più preciso è quello di compilare un ed eseguire un programma che stampa sizeof(void*)o sizeof(size_t)- call getconfpuò solo fornire informazioni su ciò che getconfpensa sia il compilatore predefinito.

— Gilles 'SO- smetti di essere malvagio'
fonte

In effetti, Solaris a 32 bit passa alla modalità 64 bit per passare al processo a 64 bit e poi tornare indietro? Questo deve avere un enorme sovraccarico e non ha senso, perché il kernel ha effettivamente 64 bit.

— Ruslan,

@Ruslan Perché dovrebbe avere un enorme sovraccarico? Il cambio di modalità su un cambio di contesto non costa molto (semmai, non conosco abbastanza bene x86 a un livello basso). Il kernel rimane a 32 bit: indirizzi virtuali a 32 bit per i mapping del kernel, uso di 32 bit del set di istruzioni.

— Gilles 'SO- smetti di essere malvagio' il

Il kernel deve mantenere alcune strutture di dati specifiche a 64 bit per supportare app a 64 bit, tabelle di pagine con almeno 64 bit. Questo non lo rende davvero un kernel a 32 bit. Non ho provato ad approfondire l'arco di amd64, ma penso che disattivare il supporto a 64 bit avrà un notevole sovraccarico rispetto all'utilizzo della modalità di compatibilità appositamente progettata.

— Ruslan,

@Ruslan Solo tabelle di pagine a 64 bit e veramente necessarie, ed è un costo minuscolo. Tutto il resto può essere evitato con il giusto design del kernel. Non ho mai scavato nel kernel di Solaris, presumo che abbiano organizzato per renderlo abbastanza flessibile (avevano precedenti esperienze con SPARC64).

— Gilles 'SO- smetti di essere malvagio' il