CODEWITHSUNDEEP
elfdwarf
Tickle
Tickle

Reputation: 21

Can't parse DWARF - Tricore CPU's DWARF info

I am struggling to parse ELF file - DWARF contents of *.elf after compilation by Tasking compiler for Infineon's Tricore CPU. I can't match the .debug_abbrev and .debug_info, to me it looks the contents are corrupted. Can you guys guide me how to parse the .debug_info contents?

.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)
...

With above .debug_abbrev contents I tried to parse the .debug_info contents, however it's very weird, maybe wrong parsing is made, and also further parsing do not match, make weird result. I guess something wrong is made by my parser but I cannot understand why.

.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 (??? how should I parse them???)
There is no 06 (for matching code 06)... I cannot perform parsing anymore.

For beginning part of .debug_info I well parsed, but from above point I can't totally understand how I need to handle the values. I also read DWARF pdf files but no more detailed description was found.

Please guide me how I should have more detailed understanding on it, thanks!

Upvotes: 1

Views: 490

Answers (2)

LXSquidFellow
LXSquidFellow

Reputation: 51

If you look at the DWARF standard (V4 at http://dwarfstd.org/Dwarf4Std.php) and find section 7.5.1.1 ("Compilation Unit Header") this will give you the info you need. From objdump --dwarf=info, here's what to look for

 $ objdump --dwarf=info mybinary
 ...
  Compilation Unit @ offset 0x8cc:
   Length:        0x2d7 (32-bit)
   Version:       4
   Abbrev Offset: 0x0                   <<<=== HERE
   Pointer Size:  8
 <0><8d7>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <8d8>   DW_AT_name        : os/signal
...

Basically each compilation unit will have a pointer in the header to the correct .debug_abbrev section that goes with that unit.

Also worth noting that .debug_abbrev tables can be shared by multiple compilation units. This happens with Go (golang) programs -- if you dump the DWARF for a Go binary you'll find that all compilation units are pointing at a single .debug_abbrev.

Upvotes: 1

Tickle
Tickle

Reputation: 21

I received some comments from other guy - then I solved that issue.

I made some misunderstanding as .debug_info should be parsed below;

1st section of .debug_info match with 1st section of .debug_abbrev,

2st section of .debug_info match with 2st section of .debug_abbrev,

3st section of .debug_info match with 3st section of .debug_abbrev,

etc...

So I assumed that .debug_info's sections are always sequential thing : 01 -> 02 -> 03 -> 04 -> ...

However I found that it's not true, actually .debug_info may have not-sequential numbers.

Usually they have 01 -> 02 -> 02 -> 02 -> 03 -> 04 -> 02 -> 01 -> ...

So this difference was the reason I made misunderstanding and also the bytes of .debug_info look like do not match with .debug_abbrev.

I hope any guy who needs similar thing may not be confused as I did.

Upvotes: 1

Related Questions