Instale programas de 64 bits em um sistema operacional de 32 bits com um processador de 64 bits

8

Estou curioso. É possível instalar um programa de 64 bits em um sistema operacional de 32 bits com um processador de 64 bits?

Estou executando o Linux em um raspberry pi 3 e tento instalar uma versão mais recente do 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
fonte

1

Considere usar um sistema operacional de 64 bits. Raspbian está muito atrasado; O Fedora de 64 bits já está disponível para o RPi3 .

— Michael Hampton

19

É possível instalar um programa de 64 bits em um sistema operacional de 32 bits com um processador de 64 bits?

Em princípio, sim, mas o processador e o sistema operacional precisam suportá-lo.

No ARMv8, um kernel de 32 bits (Aarch32) não pode executar processos de 64 bits (Aarch64). Essa é uma limitação do processador.

Existem outros processadores que não têm essa limitação; por exemplo, é possível executar processos x86_64 em cima de um kernel x86_32 em um processador x86_64, mas poucos kernels o suportam, presumivelmente porque é de utilidade limitada (principalmente, você salva um pouco de RAM no kernel, tornando-o em 32 bits). O Linux não suporta, mas o Solaris sim.

Você pode manter seu sistema operacional de 32 bits existente se executar um kernel de 64 bits . Um kernel Linux Aarch64 pode executar processos Aarch32. O Raspbian não suporta isso imediatamente, então você precisa manter um sistema operacional de 32 bits e um sistema operacional de 64 bits. Você pode usar um como o sistema operacional principal (ou seja, aquele que executa o init e os serviços do sistema) e o outro para executar um programa específico usando o chroot. Consulte Como executo programas de 32 bits em um Debian / Ubuntu de 64 bits? para uma abordagem prática.

Observe que você precisará instalar todas as bibliotecas que o programa de 64 bits exige. Qualquer processo deve ser totalmente de 32 ou 64 bits; portanto, você não pode usar uma biblioteca de 32 bits em um executável de 64 bits.

A menos que você tenha motivos fortes para manter um sistema de 32 bits, se precisar executar um executável de 64 bits, seria mais fácil instalar um sistema de 64 bits.

Observe que a única coisa que os programas de 64 bits podem fazer, mas os programas de 32 bits não conseguem, é endereçar mais de 3 GB de memória virtual, que é de utilidade limitada em um sistema com 1 GB de RAM. Você pode obter benefícios de desempenho com registros maiores e extras, mas também perde desempenho com os acessos extras à memória.

— Gilles 'SO- parar de ser mau'
fonte

3

@Wildcard Em poucas palavras, a qualquer momento, o processador está no modo de 32 bits (“estado de execução do Aarch32”) e espera instruções do Aarch32, ou no modo de 64 bits, esperando instruções do Aarch64. A única maneira de alternar modos é alternar entre processo e kernel (ou kernel e hypervisor, ou hypervisor e monitor). Alternar para um modo de privilégio inferior não pode alternar de 32 bits para 64 bits, e alternar para o modo de privilégio superior sempre restaura o modo anterior. Portanto, é impossível organizar a execução de um código de 32 bits com privilégios mais altos que o código de 64 bits.

— Gilles 'SO- stop be evil' (

2

@Wildcard (cont.) Presumivelmente, o motivo dessa restrição é que há bastante estado do processador específico do Aarch64 e que o código do Aarch32 não pode acessar. Por exemplo, um kernel do Aarch32 seria incapaz de salvar os registros de um processo do Aarch64.

— Gilles 'SO- stop be evil' (

2

@crellee, Gilles: Você não precisa olhar para sistemas operacionais exóticos para encontrar exemplos de kernels de 32 bits com terras de usuário de 64 bits. Os kernels extremamente populares do Mac OS X 10.4 "Tiger", 10.5 "Leopard" e 10.6 "Snow Leopard" enviados na configuração K32 para quase todos os Macs, exceto por algumas máquinas servidoras autorizadas a inicializar o K64 do Snow Leopard , mas todas eles eram capazes de executar processos de terra de usuário de 64 bits (com progressivamente menos restrições).

— Iwillnotexist Idonotexist

3

@Serge: O que você descreve é verdadeiro para 286 -> 386: você pode usar o tamanho de operando de 32 bits no modo real de 16 bits com prefixos, onde o tamanho padrão do operando é 16. Mas a Intel nem desenvolveu o x86-64; era a AMD (e é por isso que às vezes ainda é chamada AMD64). E não, você não pode usar o tamanho de operando de 64 bits no modo de 32 bits. Os prefixos REX redirecionam os opcodes de um byte inc/ decregistro ( 0x40 .. 0x4F). No modo longo (modo de 64 bits), o tamanho padrão do operando é 32, mas o tamanho padrão do endereço é 64.

— Peter Cordes

2

@Wildcard: IDK se o espaço de usuário no modo compatível / modo longo fosse uma consideração de design. Para salvar o estado do registro inteiro para comutadores de contexto, o Solaris (e OS X) ainda deve estar no modo longo para acessar r8-r15 e as metades superiores do rax-rsi. IDK se xsave/ xrstorno modo compat também puder salvar o estado vetorial completo. Portanto, certamente não é bem suportado ou explicitamente atendido. Provavelmente, os pontos de entrada do kernel são executados no modo de 64 bits (longo) e alternam para o modo de 32 bits (compat) antes de pular para o restante do kernel. (interruptor de modo x86 só tem um far jmpe não afeta regs.)

— Peter Cordes

5

Em algumas arquiteturas, sim. Mas não no ARM ou no x86.

Você pode usar o QEMU para emular um sistema de 64 bits, mas não deseja.

— Ignacio Vazquez-Abrams
fonte

Seria um desastre usar um emulador como o QEMU para instalar e executar um banco de dados mongo?

— crellee

Seria muito, muito lento. E não vale a pena, já que o RPi3 possui apenas 1 GB de RAM. Considere criar um pacote de 32 bits.

— Ignacio Vazquez-Abrams

2

Você pode executar um programa de 64 bits em cima de um kernel de 32 bits no x86 se o kernel suportar. Linux não, mas Solaris sim. No braço, não é possível.

— Gilles 'SO- stop be evil' (

@ IgnacioVazquez-Abrams Tente isso. É lento, mas não catastroficamente. O principal motivo é que o qemu faz emulação de CPU apenas no espaço do usuário, as chamadas do kernel (ou seja, os tempos de espera io) permanecem os mesmos. Em sistemas domésticos, eu gosto de usar binários arm ou mips para algumas ferramentas, apenas por diversão :-) Ou, às vezes, se não houver uma carga de CPU muito grande, algumas ferramentas críticas à segurança, mas não intensivas em CPU, podem usar algumas arquitetura exótica, para diminuir a probabilidade de ataques de saturação de buffer.

— peterh - Restabelece Monica 12/12

4

Atualize apenas seu kernel para um de 64 bits, para que você possa executar binários de 64 bits. Essencialmente, ele executará toda a sua distribuição no modo compatível de 32 bits e seu único mongodb de 64 bits será o modo normal.

Mas não merece seu preço. Melhor mudar o seu mongodb para 32 bits. No entanto, neste caso, há uma limitação: seu banco de dados não pode ser maior que 2 GB, pois mapeia diretamente tudo na memória virtual. Se o seu banco de dados for maior, apenas a atualização do kernel permanecerá. (Obrigado @duskwuff a extensão!)

Aliás, se o seu banco de dados não quiser uma carga muito grande, ou você pode usar alguma solução de cache antes (por exemplo: outro, mas mongo de 32 bits), uma emulação de CPU pode funcionar. Para isso, inicie uma busca no Google por "qemu qemu-system-x86_64". Embora essa solução tenha provavelmente uma necessidade de trabalho inviável e possa ser considerada estranha no ambiente produtivo.

Em seu lugar, eu usaria o mongo de 32 bits, se for suficiente para o meu db, ou um kernel de 64 bits, se não for.

— peterh - Restabelecer Monica
fonte

Faz sentido, mas como você mudaria seu mongodb para 32 bits?

— crellee

@crellee apt-get install mongodb:i386ou algo parecido?

— peterh - Restabelece Monica

que retornará um erro 'Não foi possível localizar o pacote mongodb: i386'

— crellee 11/17/17

1

Executar um MongoDB de 32 bits é uma má ideia. O banco de dados é mapeado na memória, portanto, sua execução em um sistema de 32 bits limita você a <2 GB de dados.

— duskwuff -inactive-

Sim, e você está limitado à versão: 2.4.14, que possui muitas limitações.

— crellee

3

Eu diria que não é impossível, mas é realmente difícil de gerenciar. Como um sistema operacional de 32 bits geralmente é empacotado com (e aceita) apenas binários e bibliotecas de 32 bits, você precisará ajustar bastante o sistema para fazê-lo funcionar com os de 64 bits.

O principal problema que você enfrentaria com um RPI3 é a falta de kernel de 64 bits (pelo menos com raspbian).

Para encurtar a história: use binários de 32 bits e você ficará bem.

EDIT:

Se você deseja usar um kernel de 64 bits, precisará instalar uma distribuição que suporte a arquitetura ARM64. Você deve dar uma olhada no ArchLinux ARM ( aqui ), mas ele não é totalmente suportado.

As informações que você está procurando estão na parte inferior da guia de instalação.

Você também pode dar uma olhada em uma porta oficial do debian , no entanto, ainda existem grandes problemas com a porta RPI3, então cabe a você decidir se vale a pena.

O problema é que a CPU é iniciada (pelo kernel) no modo de 32 bits, então parece uma máquina antiga de 32 bits. Registradores e instruções de 64 bits não estão disponíveis.

— Johan Myréen

1

Certo, é por isso que você precisaria de um kernel de 64 bits (que Thomas mencionou).

— Stephen Kitt

Obrigado pela boa explicação. Portanto, a solução para mim seria instalar outro sistema operacional no meu RPI3?

— crellee

Acabei de atualizar minha resposta.

@ Thomas, algumas distribuições suportam operação combinada de 32/64 bits, começando com a variante de 32 bits. O Debian é um exemplo, pelo menos no x86: você pode instalar a i386variante, e isso inclui um kernel de 64 bits, que também permite a instalação de bibliotecas e binários de 64 bits. O suporte ao ARM no Debian não permite isso em sistemas ARM (mas você pode instalar o combinado arm64e armhf, se você começar com arm64).

— Stephen Kitt

1

Eu usei um kernel de 64 bits com um sistema de 32 bits por um bom tempo (esse é o pré-requisito mínimo para executar executáveis de 64 bits nativamente, além de todas as bibliotecas de 64 bits necessárias). Eu não recomendaria. O que finalmente me fez atualizar para um sistema de 64 bits no atacado foi a constatação de que os cabeçalhos da ALSA, particularmente no que diz respeito às chamadas Midi ioctl, não eram independentes de tamanho, o que significa que as coisas compiladas no modo de 32 bits não interoperariam bem com o kernel de 64 bits.

É claro que isso pode ser considerado um bug que vale a pena consertar, mas o ritmo do desenvolvimento da ALSA está praticamente congelado e eu não podia esperar alguns anos para que o suporte à plataforma mista fosse corrigido (e de maneira compatível não-binária para não-misturados executáveis) quando o interesse em plataformas mistas está diminuindo rapidamente de qualquer maneira.

Para algumas aplicações, as coisas funcionam no modo misto (surpreendentemente, na verdade), mas se você estiver fazendo mais do que o compartilhamento básico de interface com o kernel, mesmo através de bibliotecas externas, é simplesmente super otimista.