One of the typical purposes of modifying binary files after they have been compiled is to separate the debugging symbols and sections and the real executable. If you compiled you binary with debugging information (option '-g' in gcc), the size of the binary will grow a lot due to the extra symbols, sections and human-readable stuff stored within the binary. That information is really useful when you are debugging your app, anyway, so you don't really want to completely get rid of it.

So, we can use objcopy to move all the debugging information from the binary to another file, so that:

• Binary is smaller
• Binary does not include any 'human-readable' information of the program
• Debugging information can be kept by the developers, so that if any 'core' file is received for that specific binary, debugging with GDB is possible.

[Step 1] Copy the binary to another file, keeping only the debugging information. This will create the symbol file for the binary, and will be kept by the developers of the program for debugging purposes:

objcopy --only-keep-debug $BINARY_PATH $DEBUG_INFO_FILE


[Step 2] Once you have created the symbol file, you can now remove all the debugging information from the binary itself:

objcopy --strip-debug $BINARY_PATH


[Step 3] After you have created both files, an extra optional option is to add a debug-link to the binary, to specify which is the exact file containing the debug information for that binary:

objcopy --add-gnu-debuglink=$DEBUG_INFO_FILE $BINARY_PATH

Please note that this third step is optional, as we can use specific GDB commands when debugging a core file to specify in which file the debug information is located.

[References]

1. http://sourceware.org/binutils
2. http://www.gnu.org/software/binutils

O problema

Recentemente eu precisei do binário de um programa (o software pré-compilado) para utilizar no Gentoo. Esse programa era o make [1]. Logo, não era possível utilizar o emerge e muito menos acessar o repositório do projeto GNU, fazer o download do código-fonte e compilá-lo manualmente. Como, normalmente o desenvolvedor não oferece pacotes pré-compilados, eu tinha duas opções. A primeira, entrar com o Live CD e copiar o respectivo arquivo, a outra seria utilizar algum arquivo pré-compilado de outras distribuições, como o Debian, Ubuntu, etc. Por razões práticas optei pela segunda.

Procedimento

Para o processo, utilizaremos basicamente programas no canivete suíço no UNIX, principalmente os utilitários dos pacote binutils [2]. Depois de efetuar o download:

# wget http://ftp.br.debian.org/debian/pool/main/m/make-dfsg/make_3.81-2_i386.deb
# file make_3.81-2_i386.deb
make_3.81-2_i386.deb: Debian binary package (format 2.0)

Para listar os símbolos desse arquivo, utilizaremos o nm:

# nm -s make_3.81-2_i386.deb
nm: debian-binary: File format not recognized
nm: control.tar.gz: File format not recognized
nm: data.tar.gz: File format not recognized

Podemos ver que existem 3 arquivos: debian-binary, control.tar.gz e data.tar.gz. Vamos extraí-los com o ar, uma ferramenta para criar, modificar e extraír de arquivos, mais informações nas páginas do man ou aqui.

# ar -x make_3.81-2_i386.deb

Analisando cada arquivo temos:

# cat debian-binary
2.0

Que são informações da versão do binário, o próximo arquivo (control.tar.gz) armazena informações sobre o pacote

# tar zxvf control.tar.gz
./
./control
# cat control
Package: make
Version: 3.81-2
Section: devel
Priority: standard
Architecture: i386
Depends: libc6 (>= 2.3.6-6)
Suggests: make-doc-non-dfsg
Installed-Size: 1572
Maintainer: Manoj Srivastava
Source: make-dfsg
Description: The GNU version of the "make" utility.
GNU Make is a program that determines which pieces of a large
program need to be recompiled and issues the commands to recompile
them, when necessary. More information about GNU Make can be found in
the `make' Info page. The upstream sources for this package are
available at the location ftp://ftp.gnu.org/gnu/make/. The
documentation for this package does not meet the Debian Free Software
Guidelines, and has been removed from this package.

Faltando apenas o programa propriamente dito, no arquivo data.tar.gz, eu recomendo descarregar os arquivos em um pasta separada e depois copiar apenas o que interessa, em outras palavras, você pode descarregar os arquivos na raíz do sistema e ele ficar nas pastas do sistema ou então criar um diretório qualquer (mkdir ~/teste) e fazer tudo lá. No meu caso eu copiei apenas o executável para a pasta /usr/bin do sistema.

# tar zxvf data.tar.gz
./
./usr/
./usr/bin/
./usr/bin/make
./usr/lib/
./usr/share/
./usr/share/man/
(...)

Pronto! No meu caso eu pude recuperar o make no meu sistema.

Conclusões

Há programas que fazem isso automaticamente como o deb2targz, o objetivo é apresentar o conceito por trás do formato .deb. Esse método é uma solução paliativa, pode não funcionar em casos de programa com muitas dependências, exceto se você arrumá-las, mas aí é preferível usar o gerenciador de pacotes da sua distribuição (apt, emerge, yum). Em posts futuros apresentarei outros formatos de arquivos, como o rpm, e maneiras de trabalhar com seu conteúdo.

Referências
http://www.gnu.org/software/make/
http://www.gnu.org/software/binutils/
http://www.miketaylor.org.uk/tech/deb/

A única diferença é que, infelizmente, não há suporte para arquivos-objeto ELF ainda (binutils versão 2.18), só COFF. E, esquisitamente, só permite rodar o configure, se o alvo (--target) for z80-unknown-coff. O resto seguiu sem maiores problemas.

Meus agradecimentos à WikiTI por me dar essa informação sem saber =]

Ao menos no caso do m68k e no x86_64 (amd64), a biblioteca deve vir depois de quem a precisa. Caso contrário, os símbolos contidos serão descartados, pensando-se ser inúteis.

Portanto, em vez de:
$ gcc -L. -lengine main.o -o programa

O correto é:
$ gcc -L. main.o -lengine -o programa

Ou, usando o ld:
ld -static principal.elf -L. -lengine -o jogo.elf

A posição do argumento -L não tem importância.

O post foi corrigido.

Descobri, em sites por aí, que uma biblioteca é uma coleção de arquivos objetos bem indexados. O binutils nos fornece a ferramenta necessária para sua geração, o ar (GNU archiver).

Desejando-se construir uma biblioteca de nome Engine, por exemplo, constituída pelos arquivos objetos som.elf, video.elf e chars.elf, faz-se algo assim:

$ ar rc libengine.a som.elf video.elf chars.elf
$ ranlib libengine.a

O argumento rc na verdade são 2: "r" e "c". O "c" indica que é para criar a biblioteca se ela não existir. Conforme o próprio manual, essa opção é só para não emitir uma mensagem de aviso: a biblioteca é gerada em todo caso. O argumento "r" é para indicar que, se a biblioteca já existe e já contém o arquivo video.elf, por exemplo, que o substitua pela versão mais nova.

O nome da biblioteca sempre deve começar com lib (de library) e sua extensão oficial para estática é .a.

O comando ranlib serve para garantir a agilidade (em tempo de compilação) do índice de símbolos (nomes de funções, variáveis, etc.) dos arquivos contidos na biblioteca, bem como garantir que a ordem do arquivamento não influencie em nada. Muitas vezes, o próprio ar faz isso, mas é para garantir =].

Para realizar uma ligação com a biblioteca usa-se dois parâmetros do ld: -l (ou --library=) e -L (ou --library-path=).

No caso do Mega:

$ m68k-megadrive-elf-ld -static principal.elf -L. -lengine -o jogo.elf

• -lengine: a biblioteca. Suprime-se o "lib" inicial do nome e a extensão ".a".
• -L.: um dos caminhos para procurar as bibliotecas a linkar é o diretório atual (. - ponto)
• -static: só para assegurar que a ligação é estática. Se existir uma biblioteca de mesmo nome, mas dinâmica, ignorá-la e usar a sua versão estática.

Se for desejado usar direto pelo gcc, seria algo assim:

$ gcc -static principal.c -L. -lmedia -o prog_ligacao_estatica

Próximo tópico, geração do gcc para Megadrive.

Editado: A ordem aparentemente importa nos parâmetros... Ao menos para o m68k e x86_64 (AMD64). Referenciei a biblioteca depois de ela se fazer necessária e tudo deu certo =)

Modularizar quase sempre em dividir o código em arquivos fontes diferentes. Ou seja, implica em montagem/compilação por partes. Por exemplo, dividir o jogo em 3 arquivos 1) "cabeçalho da ROM" (cabecalho.s) e 2) instruções do processador (codigo.s) 3) imagem da tela de abertura (imagem.s).

Para "compilar" (o correto em assembly é "montar") isso:
$ m68k-megadrive-as -m68000 cabecalho.s -o cabecalho.elf
$ m68k-megadrive-as -m68000 codigo.s -o codigo.elf
$ m68k-megadrive-as -m68000 imagem.s -o imagem.elf

Como fazer tudo isso virar um único arquivo? Esse processo é chamado de ligação (linkagem ou link) e o programa GNU que faz isso é o ld (GNU linker).

Teoricamente, poderia se fazer desta forma:
$ m68k-megadrive-ld cabecalho.elf codigo.elf imagem.elf -o jogo.elf
$ m68k-megadrive-objcopy -O binary jogo.elf -o jogo.bin
No entanto, a saída pode não sair da forma esperada. Se ordem dos parâmetros for diferente (imagem.elf cabecalho.elf codigo.elf), o arquivo elf de união pode sair em uma ordem interna diferente. O problema é o objcopy, que, quando passa para o formato binário (dump de memória), ele segue a ordem das seções internas do elf, pelo que entendo. Isso faz com que o cabeçalho não fique necessariamente no começo da ROM, como é obrigatório ser. Quem determina essa ordem, é a seqüência dos arquivos objetos passadas ao ld. No entanto, como não sei se essa regra da ordem é ainda realmente válida e nem por quanto tempo vai durar, segue aqui uma forma segura de corrigir isso.

É necessário obrigar, então, com que o elf da união dos códigos esteja bem ordenado (sem se preocupar com a ordem dos parâmetros): que o cabeçalho fique na posição 0x00000000, que o código comece, por exemplo (o caso padrão), na posição 0x00000200, etc. Para ter esse controle, é preciso escrever um script pro linker que ordene as coisas da forma correta. O script é um arquivo texto comum contendo algo assim:

SECTIONS {
_cabecalho 0x00000000 :
{
*(cabecalho)
}
_principal 0x00000200 :
{
codigo.elf(.text)
}
_resto :
{
*(*)
}
}

Da forma como o script está escrito, o elf gerado (jogo.elf - nome definido na linha de comando) terá 3 sessões: _cabecalho (localizada na posição 0x00), _principal (residindo na posição 0x0200) e _resto. Nessa nova sessão chamada _cabeçalho , estará o código (no caso, serão apenas dados) assembly que estiver na seção cabecalho de qualquer .elf passado na linha de comando do ld. As instruções iniciais do jogo devem estar escritas no arquivo codigo.elf. A seção .text (que implica em ser código, em geral) dele ficará na posição 0x200. Por fim, vêm todas as outras seções e arquivos .elf não contemplados.

Isso não funcionou aqui. O objcopy descartou a seção _cabeçalho pelo fato de eu não ter usado nenhuma referência de lá em lugar algum, tornando-o desnecessário.

O script então ficou assim:
SECTIONS {
rom 0x00000000 :
{
*(cabecalho)
codigo.elf(.text)
}
resto :
{
*(*)
}
}

Para realizar a ligação, então fica:

$ m68k-megadrive-ld -dT ldscript cabecalho.elf codigo.elf imagem.elf -o jogo.elf
$ m68k-megadrive-objcopy -O binary jogo.elf -o jogo.bin

Repare que para chamar o script, usei a opção -dT .

E, assim, consegui fazer a geração do binário para o megadrive a partir de vários arquivos-objetos.

Obs.: Para quem tentar usar a diretiva assembly .org um aviso: no GNU assembler, ele dita a posição relativa na seção do .elf em questão (chama-se location counter ou lc), e não a posição absoluta que a diretiva ORG que a maioria dos assembler faz acontecer.

Aqui está como eu fiz para gerar meu gas - o GNU assembler - (meus passos foram baseados na fonte Marc's Realm):

Primeiro, obtive a versão mais nova do binutils, que no caso foi a 2.18. Então, descompactei o arquivo com "tar jxf binutils-2.18.tar.bz2". Ele cria uma pasta chamada binutils-2.18.

Criei um diretório chamado binutils-build, onde ficará os arquivos de compilação do binutils, deixando a árvore do código fonte intacta.

De dentro desse diretório, via terminal, chamei o script configure do binutils:

$ ../binutils-2.18/configure --prefix=/opt/m68k --target=m68k-megadrive-elf --disable-libada --disable-libssp

Lembrando:

• --prefix diz a pasta onde será instalado o programa pelo comando make install. É opcional, mas prefiro não deixar nas pastas convencionais.
• --target indica para qual arquitetura e/ou processador as ferramentas gerarão o código.
• O alvo (m68k-megadrive-elf) é dividido em 3 partes: X-Y-Z, sendo X o processador (família m68k), Y é o nome da plataforma (à escolha: linux, jumento, unknown, etc.), e Z é o formato do arquivo de saída (no caso, elf).
• --disable-libada desabilita a compilação da biblioteca ADA, completamente desnecessária para o meu caso.
• --disable-libssp inibe a compilação da biblioteca SSP, que não sei para que serve, então não preciso ;)

Após realizada a geração dos makefiles, hora de gerar os binários!

$ make

Feito isso com sucesso, basta instalar as ferramentas como super-usuário (root):

$ su -c "make install"

Lembre-se de colocar o diretório do prefix (caso tenha usado essa opção) na variável de ambiente $PATH para atalhar as coisas!

export PATH=$PATH:/opt/m68k

Inclua isso, por exemplo, no arquivo .bashrc.

Agora, terás o assembler (e outras ferramentas úteis) para m68k!

• m68k-megadrive-elf-as: o assembler
• m68k-megadrive-elf-objcopy: converte de elf/coff para binário
• m68k-megadrive-elf-ld: o linker

Para gerar um arquivo binário para o Megadrive, deve fazer:

$ m68k-megadrive-elf-as -m68000 codigo.s -o codigo.elf
$ m68k-megadrive-elf-objcopy -O binary codigo.elf codigo.bin

Et voilà! Seu jogo em formato direitinho pro Megadrive e emuladores.

Inconveniente do processo: O assembler gerado é para a família m68k, isso quer dizer que variantes como 68010 e 68020 também podem ser montados. Como o Mega só usa o 68000, os programas são desnecessariamente maiores. E o pior: o 68020 é dado como padrão. Isso implica em ficar definindo toda vez que for montar que o processador é o 68000 e não o 68020. Só descobri uma forma de definir o 68000 como único processador de montagem: ao realizar o configure do binutils, definir o alvo (target) como m68000-megadrive-elf. Entretanto, isso elimina a opção -m68000 (desnecessária, agora) do assembler, o que estraga as coisas para a compilação do gcc, que mostrarei em um post futuro...

Se alguém souber como definir pro assembler o processador 68000 como padrão, agradeço.