Como é que um sistema operacional afetam como montagem de código é executado?

Question

Eu estou esperando para aprender linguagem assembly para x86. Eu estou em um Mac, e eu estou supondo que a maioria dos tutoriais x86 / livros usar o código que é destinado para Windows.

Como é que o sistema operacional que o código é executado em afetam o que o código faz, ou determinar se o código funciona mesmo? Eu poderia seguir um tutorial baseado no Windows, e modificar alguns comandos para fazer o trabalho para Mac com relativa facilidade? De modo mais geral, há algo complicado que um Mac montagem programador, especificamente, deveria saber? Obrigado!

Answer 1

(Claro, todo o seguinte aplica-se única para x86 e x86-64 linguagem assembly, para processadores e sistemas operacionais IA-32 e AMD64.)

As outras respostas visível no momento estão todos corretos, mas, na minha opinião, perder o ponto. AT & T contra sintaxe Intel é uma não-questão completo; qualquer ferramenta decente vai trabalhar com as duas sintaxes ou ter uma contrapartida ou substituição que faz. E eles montam o mesmo de qualquer maneira. (Protip: você realmente quer usar a sintaxe Intel Toda a documentação oficial processador faz AT & T sintaxe é apenas uma dor de cabeça gigante...) Sim, encontrar as bandeiras certas para passar para a montador e ligador pode ser complicado, mas você saberá quando você tem isso e você só tem que fazer isso uma vez por OS (se você se lembrar de anotá-la em algum lugar!).

As instruções de montagem próprios, é claro, são completamente OS-agnóstica. A CPU não se importa o sistema operacional que está sendo executado. A menos que você está fazendo extremamente hackery de baixo nível (ou seja, o desenvolvimento OS), as porcas e parafusos de como o sistema operacional e CPU interagem são quase totalmente irrelevante.

The Outside Mundial

O problema com a linguagem assembly vem quando você interage com o mundo exterior: o kernel do sistema operacional, e outro código de espaço do usuário. Userspace é mais complicada: você tem que ter o direito ABI ou o seu programa de montagem é tudo, mas inútil. Esta parte geralmente não é portátil entre sistemas operacionais menos que você use trampolins / thunks (basicamente uma outra camada de abstração que tem que ser reescrito para cada sistema operacional que você pretende suporte).

A parte mais importante da ABI é tudo o que a convenção de chamada é para as funções de estilo C. Eles são o que são mais comumente apoiada, eo que você provavelmente vai ser a interface com se você estiver escrevendo montagem. Agner Nevoeiro mantém vários recursos bons sobre seu local ; descrição detalhada de chamar convenções é particularmente útil. Em sua resposta, Norman Ramsey menciona PIC e bibliotecas dinâmicas; na minha experiência você geralmente não tem que se preocupar com aqueles que você não quer. vinculação estática funciona bem para usos típicos de linguagem assembly (como reescrever funções essenciais de um circuito interno ou outro hotspot).

A convenção de chamada funciona em duas direções: você pode chamar C de montagem ou montagem de C. O último tende a ser um pouco mais fácil, mas não há uma grande diferença. Chamando C de montagem permite que você usar coisas como as funções de saída biblioteca C padrão, enquanto chamando a montagem de C é tipicamente como você acessar uma implementação montagem de uma única função de desempenho crítico.

Sistema de Chamadas

A outra coisa que seu programa vai fazer é chamadas de sistema faz. Você pode escrever um programa conjunto completo e útil que nunca chama funções C externos, mas se você quer escrever um programa em linguagem assembly puro que não terceirizar as coisas divertidas para alguém do código, você está indo para necessidade chamadas do sistema. E, infelizmente, chamadas do sistema são totalmente e completamente diferente em cada sistema operacional. sistema Unix-style chama você precisará incluem (mas com toda a certeza não estão limitados a!) open, creat, read, write, eo exit muito importante, juntamente com mmap se você gosta de alocação de memória dinâmica.

Enquanto cada sistema operacional é diferente, sistemas operacionais mais modernos seguem um padrão geral: você carregar o número da chamada de sistema que você quer em um registrador, tipicamente EAX no código de 32 bits, em seguida, carregar os parâmetros (como fazer isso varia muito ) e, finalmente, emitir um pedido de interrupção: É INT 2E para Windows NT kernel ou INT 80h para Linux 2.x e FreeBSD (e, creio eu, OSX). O kernel então assume, executa a chamada de sistema, e retorna EXECUTion para o seu programa. Dependendo do sistema operacional, pode lixo registros ou pilha como parte da chamada de sistema; você terá que certifique-se de ler a documentação chamada de sistema para a sua plataforma para ter certeza.

SYSENTER

Linux kernel 2.6 (e, creio eu, o Windows XP e mais recentes, embora eu nunca tenha realmente tentado-lo no Windows) também suportam um método mais novo, mais rápido para fazer uma chamada de sistema: a instrução SYSENTER introduzido pela Intel em novos chips Pentium . chips AMD tem SYSCALL, mas poucas de 32 bits sistemas operacionais usá-lo (apesar de ser o padrão para 64 bits, eu acho, eu não tive para fazer chamadas de sistema diretos de um programa de 64 bits, então eu não tenho certeza sobre isso ). SYSENTER é significativamente mais complicado de configurar e usar (ver, por exemplo, Linus Torvalds na implementação SYSENTER suporte para Linux 2.6 : "Eu sou um porco nojento, e orgulhoso dele para boot") Eu posso pessoalmente atestar a sua peculiaridade; Uma vez escrevi uma função de montagem que emitiu SYSENTER diretamente para um kernel Linux 2.6, e eu ainda não entender os vários pilha e registrar truques que tenho que trabalhar ... mas o trabalho que fez!

SYSENTER é um pouco mais rápido do que a emissão de INT 80h, e por isso seu uso é desejável quando disponível. Para torná-lo mais fácil de escrever rápido e código portátil, Linux mapeia um VDSO chamado linux-gate no espaço de endereço de cada programa; chamar uma função especial neste VDSO irá emitir uma chamada de sistema pelo mecanismo mais rápido disponível. Infelizmente, a utilização é geralmente mais problemas do que vale a pena: INT 80h é muito mais simples para fazer em uma rotina de montagem pequena que vale a pena a pequena velocidade penalidade. A menos que você precisa o melhor desempenho ... e se você precisa disso, você provavelmente não quer pôr em um VDSO qualquer maneira, e você sabe que seu hardware, assim você pode simplesmente fazer a coisa e emissão terrivelmente inseguro SYSENTER si mesmo.

Outros

Além das exigências impostas pela interação com o kernel e outros programas, há muito, muito poucas diferenças entre os sistemas operacionais. Assembléia expõe a alma da máquina: você pode trabalhar como você gosta, e dentro de seu próprio código que você não está vinculado a qualquer convenção de chamada particular. Você tem livre acesso às unidades FPU e SSE; você pode PREFETCH diretamente para transmitir dados da memória para o cache L1 e ter certeza que é quente para quando você precisar dele; você pode munge a pilha à vontade; você pode emitir INT 3 se você quer fazer a interface com um (devidamente configurado; boa sorte!) depurador externo. Nenhuma dessas coisas dependem de seu sistema operacional. A única restrição real que você tem é que você está rodando a Ring 3, não anel 0, e assim por algum processador de registros de controle não estará disponível para você. (. Mas se você precisa aqueles, você está escrevendo código OS, não o código do aplicativo) Fora isso, a máquina é posta a nu a você: vá adiante e compute

Answer 2

De um modo geral, desde que você use a mesma montadora, ea mesma arquitetura (por exemplo, NASM, e x86-64), você deve ser capaz de montar montagem em Windows e Mac.

No entanto, é importante ter em mente que os formatos executáveis ??e os ambientes de execução podem ser diferentes. Como um exemplo, o Windows pode emular / lidar com certas instruções privilegiadas de forma diferente para Mac, causando um comportamento diferente.

Answer 3

Também uma grande parte da diferença está na forma como as comunica programa com o mundo exterior.

Por exemplo, se você quiser exibir uma mensagem para o usuário ou ler um arquivo ou alocar mais memória você tem que perguntar o sistema operacional para fazê-lo, fazendo algum tipo de chamada de sistema. Isso vai ser bastante diferente entre OS de.

A linguagem sintaxe em si deve ser basicamente idêntico, desde que você está usando a mesma assembler. Diferentes montadoras, por vezes, têm ordenação ligeiramente diferente na sintaxe ou diferentes macros mas nada que é muito difícil de se acostumar.

Answer 4

The Great Divide em linguagem assembly Intel está entre a AT & T sintaxe e sintaxe Intel. Você vai querer um montador para o seu Mac que usa a mesma sintaxe que qualquer tutoriais que você usa. Como acredito MacOS Darwin, uma variante BSD, usa AT & T sintaxe, eo assembler Microsoft usa a sintaxe Intel, você precisa ter cuidado.

A outra diferença para ter cuidado com é do sistema Application Binary Interface (ABI), que abrange chamando convenções, layout de pilha, chamadas do sistema, e assim por diante. Eles podem diferir substancialmente entre OS de, especialmente quando se trata de código independente de posição e dinâmica que liga . Tenho lembranças infelizes vagas que PIC foi especialmente complicado no PowerPC MacOS, mas talvez seja mais simples sobre a Intel.

Um pedaço de aconselhar:. aprender x86_64 (também conhecido como AMD64) -é muito mais divertido para código de montagem de escrita à mão, e você estará mais preparada para o futuro

Answer 5

Quando eu mergulhado em Assembleia durante uma das minhas turístico programação visitas, a pegadinha que me ergueu em cada tutorial não estava sendo capaz de compilar no formato binário correto. A maioria dos tutoriais dar elf (para Linux) e aoutb (para BSD), ainda com o último OS X reclama (escolha lógica?):

ld: hello.o bad magic number (not a Mach-O file)

ainda Mach-O falhar como um formato, e se você man nasm você começa apenas bin, aout e arquivo elf formatos - man ld não é mais útil - macho é a opção de fazer o formato de Mach-O para OS X:

nasm -f macho hello.asm

escreveu-se a viagem aqui (inclui um link para um pacote TextMate agradável para montagem e outras informações), mas - para ser breve -. o acima é o que você precisa para começar