Impossible d'analyser DWARF - DWARF du processeur Tricore info

Question

J'ai du mal à analyser le fichier ELF - le contenu DWARF de * .elf après compilation par le compilateur Tasking pour le processeur Tricore d'Infineon. Je ne peux pas correspondre à la .debug_abbrev et .debug_info, pour moi, il semble que le contenu est corrompu. Pouvez-vous me guider pour analyser le contenu de .debug_info?

.debug_abbrev; 
... 
04 (code) 
05 (DW_TAG_compile_unit) 
00 (no child) 
03 08 (DW_AT_name, DW_FORM_string) 
3A 0F (DW_AT_decl_file, DW_FORM_udata) 
3B 0F (DW_AT_decl_line, DW_FORM_udata) 
39 0F (DW_AT_decl_column, DW_FORM_udata) 
49 13 (DW_AT_type, DW_FORM_ref4) 
00 00 (end) 

05 (code) 
35 (DW_TAG_volatile_type) 
00 (no child) 
49 13 (DW_AT_type, DW_FORM_ref4) 
00 00 (end) 

06 (code) 
0F (DW_TAG_pointer_type) 
00 (no child) 
49 13 (DW_AT_type, DW_FORM_ref4) 
00 00 (end) 
... 

Avec contenu .debug_abbrev ci-dessus, j'ai essayé d'analyser le contenu de .debug_info, mais il est très bizarre, peut-être mal est fait l'analyse syntaxique, et également d'autres parsing ne correspondent pas, faire résultat bizarre. Je suppose que quelque chose de mal est fait par mon analyseur mais je ne peux pas comprendre pourquoi.

.debug_info; 
04 (04, code) 
75 77 56 61 6C 75 65 00 (uwValue, DW_FORM_string) 
01 (1, DW_FORM_udata) 
8D 01 (8D, DW_FORM_udata) 
1F (1F, DW_FORM_udata) 
93 00 00 00 (00000093, DW_FORM_ref4) 
00 (end) 

05 (05, code) 
93 00 00 00 (00000093, DW_FORM_ref4) 

03 75 6E 73 69 67 6E 65 6E 73 69 67 (??? comment dois-je les parse ???)
Il n'y a pas 06 (pour le code correspondant à 06) ... Je ne peux pas effectuer l'analyse syntaxique plus. Pour commencer partie de .debug_info J'ai bien analysé, mais à partir du point ci-dessus je ne peux pas totalement comprendre comment je dois gérer les valeurs. J'ai aussi lu les fichiers PDF DWARF mais aucune description plus détaillée n'a été trouvée.

S'il vous plaît me guider comment je devrais avoir une compréhension plus détaillée à ce sujet, merci!

Answer 1

J'ai reçu des commentaires d'autres gars - alors j'ai résolu ce problème.

J'ai fait un malentendu car .debug_info devrait être analysé ci-dessous;

1ère section de .debug_info avec correspondance 1ère section de .debug_abbrev,

section 2er de .debug_info match de l'article 2er de .debug_abbrev,

section 3pc de .debug_info match de l'article 3pc de .debug_abbrev ,

etc ...

Je pris en charge les sections qui .debug_info sont toujours chose séquentielle: 01 -> 02 -> 03 -> 04 -> ...

Cependant, j'ai trouvé que ce n'est pas vrai, en fait .debug_info peut avoir des nombres non-séquentiels.

Habituellement, ils ont 01 -> 02 -> 02 -> 02 -> 03 -> 04 -> 02 -> 01 -> ...

donc cette différence a été la raison pour laquelle j'ai fait l'incompréhension et aussi Les octets de .debug_info ne ressemblent pas à .debug_abbrev.

J'espère que tout gars qui a besoin d'une chose similaire peut ne pas être confus comme je l'ai fait.