O que acontece quando o código assembly é convertido em código de objeto?

Question

Estou interessado no desenvolvimento do Software de Sistema. Eu tenho analisado o funcionamento de um compilador por alguns dias. Um código de montagem gerado por um compilador (digamos) clc tem um opcode f8 e tenho certeza que o Assembler que monta o mnemônico acima, substitui seu opcode f8 em seu lugar.

O que está me incomodando é o rescaldo desse estágio (estou ciente do estágio de vinculação intermediário).

Quero dizer, o que exatamente acontece depois desse estágio? Digamos que o executável final seja um arquivo binário bruto. Isso significa que o opcode f8 é convertido em dados binários 1111 1000 e armazenado no arquivo?

Se for esse o caso, por que não consigo visualizar o conteúdo binário de um arquivo binário usando um editor de texto normal (digamos, Bloco de Notas) - afinal, '0's e' 1's estão corretos?

    

Answer 1

Primeiro, use sempre a ferramenta certa para o trabalho. Editor de texto para visualizar arquivos binários é o mesmo que usar uma faca para pregar. Use qualquer viewer / editor HEX para tais tarefas ou use melhor a ferramenta que conhece internals do arquivo binário em questão. Se estamos falando sobre opcodes da CPU, então algo como IDA Pro livre ou OllyDbg seria útil para analisar internamente arquivos executáveis.

Does that mean the opcode f8 is converted into binary data 1111 1000 and stored in the file?

Como foi corretamente apontado por @Mokubai - 0xF8 é o mesmo número que 1111 1000 , um representado na notação HEX e o último como representação binária. É o mesmo que o número 248 no sistema decimal.

Se você criar código executável manualmente a partir de opcodes da CPU (ou compilar código fonte do assembler), então a CPU i386 reconhecerá 0xF8 (ou 0b11111000 ou 248 - tudo a mesma coisa) da instrução CLC .

An Assembly code generated by a Compiler(say) clc has an opcode f8 and I am sure that the Assembler assembling the above mnemonic, substitutes its opcode f8 in it's place.

Isso é verdade, exceto - "Um código de montagem gerado por um compilador". Eu só quero ter certeza que você entendeu corretamente a diferença entre "Assembly code" e opcodes. Os opcodes são uma linguagem exata que a CPU pode entender, apenas números (e é como programamos os primeiros computadores quando os tradutores de mnemônicos da CPU, também conhecidos como assembler, eram um sonho)

Atualmente, usamos principalmente a compilação "direta" da linguagem de programação de alto nível diretamente para binários executáveis com compiladores como C / C ++ / GoLang que produzem opcodes da CPU.
(Quando eu disse "compilação direta" isso não é verdade, sob compiladores que fazem várias etapas antes de produzir binários executáveis, mas para o usuário final parece o mesmo que dirigir um carro sem precisar saber como a gasolina é convertida em movimento)

Como foi mencionado corretamente pelo @sawdust no comentário, as linguagens de programação de nível superior podem usar diferentes estratégias para criar opcodes da CPU. Você pode analisar, por exemplo, gcc compilador como ele iria cozinhar opcodes, dizendo-lhe para gerar código assembler que seria usado para fazer opcodes (códigos de objeto)

 gcc -S -o myprogram.asm myprogram.c

If that is the case, why am I not able to view the binary contents of a binary file using a normal text editor(say Notepad) - after all it's '0's and '1's right?

O bloco de notas fala outro idioma. Ele entende seus próprios "opcodes" - ASCII, qualquer outra coisa é "grega" para o Bloco de Notas.