06 de abr de 2012 16:11 do Albert

onde / como o Apples GCC armazena o DWARF dentro de um executável

Onde / como o Apples GCC armazena o DWARF dentro de um executável?

Eu compilei um binário viagcc -gdwarf-2 (Maçãs GCC). No entanto, nemobjdump -g nemobjdump -h me mostra qualquer informação de depuração.

Também libbfd não encontra nenhuma informação de debug. (Eu perguntei na lista de discussão binutils sobre issoAqui.)

Eu sou capaz de extrair as informações de depuração viadsymutil (em um dSYM). O libbfd também é capaz de ler essas informações de depuração.

questionAnswers (0)

01 de fev de 2017 12:20 do Timmmm

No.o arquivos de objeto usados ​​para compilação. O binário armazena uma referência a esses arquivos (por caminho absoluto).

Em um pacote separado (diretório) chamado .dSYM

Se eu compilar com o Clang da Apple usandog++ -g main.cpp -o foo Eu recebo o pacote chamadofoo.dSYM. No entanto, se eu usar o CMake, obtenho as informações de depuração nos arquivos de objeto. Eu acho que porque faz um separadogcc -c main.cpp -o main.o degrau?

Enfim, achei esse comando muito útil para o caso 1:

<code>$ dsymutil -dump-debug-map main
---
triple:          'x86_64-apple-darwin'
binary-path:     main
objects:         
  - filename:        /Users/tim/foo/build/CMakeFiles/main.dir/main.cpp.o
    timestamp:       1485951213
    symbols:         
      - { sym: __ZNSt3__111char_traitsIcE11eq_int_typeEii, objAddr: 0x0000000000000D50, binAddr: 0x0000000100001C90, size: 0x00000020 }
      - { sym: __ZNSt3__111char_traitsIcE6lengthEPKc, ,objAddr: 0x0000000000000660, binAddr: 0x00000001000015A0, size: 0x00000020 }
      - { sym: GCC_except_table3, objAddr: 0x0000000000000DBC, binAddr: 0x0000000100001E2C, size: 0x00000000 }
      - { sym: _main, objAddr: 0x0000000000000000, binAddr: 0x0000000100000F40, size: 0x00000090 }
      - { sym: __ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m, objAddr: 0x00000000000001F0, binAddr: 0x0000000100001130, size: 0x00000470 }
      - { sym: ___clang_call_terminate, objAddr: 0x0000000000000D40, binAddr: 0x0000000100001C80, size: 0x00000010 }
      - { sym: GCC_except_table5, objAddr: 0x0000000000000E6C, binAddr: 0x0000000100001EDC, size: 0x00000000 }
      - { sym: __ZNSt3__116__pad_and_outputIcNS_11char_traitsIcEEEENS_19ostreambuf_iteratorIT_T0_EES6_PKS4_S8_S8_RNS_8ios_baseES4_, objAddr: 0x0000000000000680, binAddr: 0x00000001000015C0, size: 0x000006C0 }
      - { sym: __ZNSt3__14endlIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_, objAddr: 0x00000000000000E0, binAddr: 0x0000000100001020, size: 0x00000110 }
      - { sym: GCC_except_table2, objAddr: 0x0000000000000D7C, binAddr: 0x0000000100001DEC, size: 0x00000000 }
      - { sym: __ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc, objAddr: 0x0000000000000090, binAddr: 0x0000000100000FD0, size: 0x00000050 }
      - { sym: __ZNSt3__111char_traitsIcE3eofEv, objAddr: 0x0000000000000D70, binAddr: 0x0000000100001CB0, size: 0x0000000B }
...
</code>
06 de abr de 2012 16:32 do 28.3k

Eu seguidsymutil e lê todo o*.o arquivos.objdump -h também lista todas as informações de depuração neles.

Então parece que essas informações não são copiadas para o binário.

Alguns comentários relacionados sobre isso também podem ser encontradosAqui.

10 de out de 2012 20:05 do 10.8k

ld) não processa todas as informações de depuração ao vincular seu programa. As informações de depuração geralmente têm 10x o tamanho do executável do programa, portanto, ter o vinculador processando todas as informações de depuração e incluí-las no binário executável prejudicou gravemente os tempos de vinculação. Para o desenvolvimento iterativo - compilar, link, compilar, link, depurar, compilar link - este foi um verdadeiro sucesso.

Em vez disso, o compilador gera as informações de depuração DWARF nos arquivos .s, o montador as envia nos arquivos .o e o vinculador inclui um "mapa de depuração" no binário executável que informa aos usuários de informações de depuração onde todos os símbolos foram realocados durante a ligação.

Um consumidor (que faz depuração de arquivo .o) carrega o mapa de depuração do executável e processa todo o DWARF nos arquivos .o conforme necessário, remapeando os símbolos de acordo com as instruções do mapa de depuração.

dsymutil pode ser pensado como um linkador de informações de depuração. Ele faz o mesmo processo - leia o mapa de depuração, carregue o DWARF dos arquivos .o, realoque todos os endereços - e, em seguida, imprima um único binário de todos os DWARF em seus endereços finais vinculados. Este é o pacote dSYM.

Uma vez que você tenha um pacote dSYM, você terá o padrão DWARF antigo que qualquer ferramenta de leitura de anão (que pode lidar com arquivos binários Mach-O) pode processar.

Há um refinamento adicional que faz com que tudo isso funcione, os UUIDs incluídos nos binários do Mach-O. Toda vez que o vinculador cria um binário, ele emite um UUID de 128 bits no comando de carregamento LC_UUID (v.otool -hlv oudwarfdump --uuid). Isso identifica exclusivamente esse arquivo binário. Quandodsymutil cria o dSYM, inclui esse UUID. Os depuradores só associarão um dSYM e um executável se eles tiverem UUIDs correspondentes - nenhum timestamp de modulação de arquivo duvidoso ou qualquer coisa assim.

Também podemos usar os UUIDs para localizar os dSYMs para binários. Eles aparecem em relatórios de falhas, incluímos um importador do Spotlight que você pode usar para pesquisá-los, por exemplo,mdfind "com_apple_xcode_dsym_uuids == E21A4165-29D5-35DC-D08D-368476F85EE1" se o dSYM estiver localizado em um local indexado do Spotlight. Você pode até mesmo ter um repositório de dSYMs para sua empresa e um programa que pode recuperar o dSYM correto dado um UUID - talvez um pequeno banco de dados mysql ou algo assim - então você executa o debugger em um executável aleatório e instantaneamente informações para esse executável. Existem algumas coisas bem legais que você pode fazer com os UUIDs.

Mas de qualquer maneira, para responder sua pergunta de origem: O binário não-tirado tem o mapa de depuração, os arquivos .o têm o DWARF, e quandodsymutil é executado estes são combinados para criar o pacote dSYM.

Se você quiser ver as entradas do mapa de depuração, façanm -pa executable e eles estão todos lá. Eles estão na forma dos antigos stabs nlist records - o linker já sabia como processar stabs, então era mais fácil usá-los - mas você verá como funciona sem muitos problemas, talvez refira-se a alguma documentação de stabs se você estiver incerto.

14 de abr de 2012 14:31 do Bogatyr

os * .dSYM. Você pode executar o dwarfdump nesses arquivos e ver as Entradas de Informações de Depuração do DWARF.

yourAnswerToTheQuestion