On 19/10/21 10:42, Diego Zuccato wrote:

Il 18/10/2021 22:21, Davide Prina ha scritto:

On 18/10/21 08:49, Diego Zuccato wrote:

Ovviamente: un sistema a 64 bit può gestire una lib a 32 bit ma non
viceversa.

in teoria, con Debian, puoi creare un sistema a più architetture
hardware e quindi avere un sistema 64-32 bit... e probabilmente lo
puoi ottenere sia partendo da un sistema a 32 che da uno a 64 (ho
provato solo da amd64 aggiungere i386)

Si, puoi forse partire da uno a 32 bit, ma se il kernel non è a 64 bit,
il processore girerà solo a 32. In pratica il processore in modalità 64 bit riconosce il codice a 32 bit e va in modalità compatibile (sto semplificando al massimo). Ma se il processore è in modalità 32 bit, non sa nulla del codice a 64 bit e se va bene si blocca su un illegal opcode.

se devo essere sincero non ho mai approfondito più di tanto la questione
di quale foreign architecture puoi installare sulla tua macchina e una
volta fatto cosa effettivamente ci puoi fare.
L'unica cosa che ho fatto è installare l'architettura i386 su
un'architettura amd64.

Però se si guarda il wiki di Debian relativo alla multiarchitettura[¹]
prima indica con questa frase "either the kernel supports a
compatibility interface, notably 64bit kernels often support running
32bit software (but most probably not the converse)" che non sembra
escludere definitivamente questa possibilità, mentre io mi sarei
aspettato, come hai indicato tu, una frase che escludesse
categoricamente l'esecuzione di software a 64 bit su un'architettura
hardware a 32 bit.

Poi però offre una modalità per poter eseguire qualsiasi software di qualsiasi architettura hardware supportata da Debian sulla propria architettura hardware "nativa": "or a qemu-user instance is configured
to act as an on-the-fly emulation layer, see QemuUserEmulation" che
punta alla pagina di QemuUserEmulation[²]

Da quello che ho capito, guardando rapidamente questa seconda pagina,
sembra possibile installare software di una qualsiasi foreign
architecture ed eseguirlo in modo trasparente, come se fosse
dell'architettura "nativa".

La cosa è molto interessante e, ad avere tempo, sarebbe da sperimentare

Ciao
Davide

[¹] https://wiki.debian.org/Multiarch/HOWTO

[²] https://wiki.debian.org/QemuUserEmulation
--
Sistema operativo: http://www.debian.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

notably 64bit kernels often support running
32bit software (but most probably not the converse)" che non sembra escludere definitivamente

Se il mondo non e` cambiato nel frattempo, mi sentirei di escluderlo.
Un eseguibile a 64 bit usa puntatori a 64 bit e vuole una memoria
virtuale a 64 bit (non ricordo quanti, ma piu` di 32). Se il kernel
e` a 32 bit, offre una memoria virtuale a 32.

"or a qemu-user instance is configured
to act as an on-the-fly emulation layer, see QemuUserEmulation"

Questo funziona come un gioiellino. Ma ovviamente il codice viene
interpretato (da qemu), non eseguito, quindi va piu` lento. Qemu e` straordinariamente efficente (e` Fabrice Bellard, mica l'ultimo
pistola) ma comunque siamo circa 10x piu` lento del nativo.

La cosa è molto interessante e, ad avere tempo, sarebbe da sperimentare

E' banale. Si prende un eseguibile arm e si esegue. E` uno dei primi
esempi che faccio ai miei studenti, partendo da PC per andare su
micretto.

Certo, se e` un eseguibile "serio" occorrono anche le librerie dinamiche dell'architettura eccetera. Io lo faccio vedere senza libreria,
implementando le 2 chiamate di sistema che mi servono (write e exit):

laptopo% make hell-arm
arm-none-eabi-gcc -c -o syscalls-arm.o syscalls-arm.S
arm-none-eabi-gcc -Wall -static -ffreestanding -c -o hell.o hell.c
arm-none-eabi-ld -e main -o hell-arm syscalls-arm.o hell.o

laptopo% ./hell-arm
Hello

laptopo% file hell-arm
hell-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

laptopo% uname -m
x86_64

Il trucco sta in binfmtmisc, che definisce interpreti per vari formati
di file, in base al contenuto del file (il "magic number"):

laptopo% ls /proc/sys/fs/binfmt_misc/
cli qemu-aarch64 qemu-mips qemu-sh4
jar qemu-alpha qemu-mipsel qemu-sh4eb
llvm-3.1.binfmt qemu-arm qemu-ppc qemu-sparc
python2.6 qemu-armeb qemu-ppc64 qemu-sparc32plus
python2.7 qemu-cris qemu-ppc64abi32 qemu-sparc64
python3.2 qemu-m68k qemu-ppc64le register
python3.4 qemu-microblaze qemu-s390x status

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Oct 19, 2021 at 11:03:09PM +0200, Alessandro Rubini wrote:

notably 64bit kernels often support running
32bit software (but most probably not the converse)" che non sembra escludere definitivamente

Se il mondo non e` cambiato nel frattempo, mi sentirei di escluderlo.
Un eseguibile a 64 bit usa puntatori a 64 bit e vuole una memoria
virtuale a 64 bit (non ricordo quanti, ma piu` di 32). Se il kernel
e` a 32 bit, offre una memoria virtuale a 32.

"or a qemu-user instance is configured
to act as an on-the-fly emulation layer, see QemuUserEmulation"

Questo funziona come un gioiellino. Ma ovviamente il codice viene interpretato (da qemu), non eseguito, quindi va piu` lento. Qemu e` straordinariamente efficente (e` Fabrice Bellard, mica l'ultimo
pistola) ma comunque siamo circa 10x piu` lento del nativo.

La cosa è molto interessante e, ad avere tempo, sarebbe da sperimentare

E' banale. Si prende un eseguibile arm e si esegue. E` uno dei primi
esempi che faccio ai miei studenti, partendo da PC per andare su
micretto.

Certo, se e` un eseguibile "serio" occorrono anche le librerie dinamiche dell'architettura eccetera. Io lo faccio vedere senza libreria,
implementando le 2 chiamate di sistema che mi servono (write e exit):

laptopo% make hell-arm
arm-none-eabi-gcc -c -o syscalls-arm.o syscalls-arm.S
arm-none-eabi-gcc -Wall -static -ffreestanding -c -o hell.o hell.c
arm-none-eabi-ld -e main -o hell-arm syscalls-arm.o hell.o

laptopo% ./hell-arm
Hello

laptopo% file hell-arm
hell-arm: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

laptopo% uname -m
x86_64

Il trucco sta in binfmtmisc, che definisce interpreti per vari formati
di file, in base al contenuto del file (il "magic number"):

laptopo% ls /proc/sys/fs/binfmt_misc/
cli qemu-aarch64 qemu-mips qemu-sh4
jar qemu-alpha qemu-mipsel qemu-sh4eb
llvm-3.1.binfmt qemu-arm qemu-ppc qemu-sparc
python2.6 qemu-armeb qemu-ppc64 qemu-sparc32plus
python2.7 qemu-cris qemu-ppc64abi32 qemu-sparc64
python3.2 qemu-m68k qemu-ppc64le register
python3.4 qemu-microblaze qemu-s390x status

Alex al solito sei stellare, questa mail me la salvo...

Si lo so, dirai, banale, ok ... per te, e una volta che l'ho letta,
anche per me. È questo il punto: è tutto semplice _dopo_ che lo sai.

GRAZIE

--

Saluton,
Marco Ciampa

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ciao,

Il 2021-10-19 23:03 Alessandro Rubini ha scritto:

Il trucco sta in binfmtmisc, che definisce interpreti per vari formati
di file, in base al contenuto del file (il "magic number"):

laptopo% ls /proc/sys/fs/binfmt_misc/
cli qemu-aarch64 qemu-mips qemu-sh4
jar qemu-alpha qemu-mipsel qemu-sh4eb
llvm-3.1.binfmt qemu-arm qemu-ppc qemu-sparc
python2.6 qemu-armeb qemu-ppc64 qemu-sparc32plus
python2.7 qemu-cris qemu-ppc64abi32 qemu-sparc64
python3.2 qemu-m68k qemu-ppc64le register
python3.4 qemu-microblaze qemu-s390x status

Non vedo una definizione per wine :-)

Forse ritieni che sia troppo rischioso eseguire "inconsapevolmente" il
codice che wine farebbe girare?

In effetti concordo :-D

Ĝis,
m

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)