title: Eclipse CDT ELF Parser unnable to parse debug file
body: <p><strong>TL;DR</strong></p>
  
  <p>CDT ELF parser and ObjDump cannot parse my relocatable file, but both work properly with Executable File. I wonder if they are related.</p>
  
  <p>ObjDump has wrong abbrev offsets, CDT parser throws <em>BufferUnderflowException</em></p>
  
  <p><strong>The Problem</strong></p>
  
  <p>I'm working with Eclipse CDT ELF Parser in order to extract variable informations from my output files. With my exectuble files, it works perfectly. But with a relocatable file, it has problems to read it, but only <strong>after a certain point</strong>. </p>
  
  <p><strong>Edit:</strong> <em>It seems the buffer underflow is not really the problem, but a consequence of data misinterpretation. 
  Still testing to see how it is processing the file. I'll post more later</em></p>
  
  <p><strong>Analysis</strong></p>
  
  <p>At first I thought the dwarf section must be corrupted. Using ObjDump, the output file is incomplete with several errors. It actually only shows the types, but with wrong abbreviation numbers and <strong>offsets</strong>. </p>
  
  <p>The log message:</p>
  
  <p>$ C:\MinGW\bin\objdump.exe --dwarf %MYFILE% > %MYFILE%_objdump.txt </p>
  
  <pre><code>C:\MinGW\bin\objdump.exe: Warning: DIE at offset 0x1a9 refers to abbreviation number 8020 which does not exist
  C:\MinGW\bin\objdump.exe: Warning: DIE at offset 0x1a9 refers to abbreviation number 8020 which does not exist
  C:\MinGW\bin\objdump.exe: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_loc section.
  C:\MinGW\bin\objdump.exe: Warning: Unable to load/parse the .debug_info section, so cannot interpret the .debug_ranges section.
  </code></pre>
  
  <p>Using readelf, however, it can read it perfectly, with all the sections and symbols. Regarding the other binaries, the readelf and the objdump outputs are the same.</p>
  
  <p>In the debug_info with objdump I have for example:</p>
  
  <pre><code>Compilation Unit @ offset 0x170:
    Length:        0x7dc (32-bit)
    Version:       3
    Abbrev Offset: 0x0
    Pointer Size:  4
  
  &lt;0&gt;&lt;17b&gt;: Abbrev Number: 1 (DW_TAG_compile_unit)
     &lt;17c&gt;   DW_AT_producer    : (indirect string, offset: 0x0): object
     &lt;180&gt;   DW_AT_language    : 4    (C++)
     &lt;181&gt;   DW_AT_name        : (indirect string, offset: 0x0): object
     &lt;185&gt;   DW_AT_comp_dir    : (indirect string, offset: 0x0): object
     &lt;189&gt;   DW_AT_low_pc      : 0x0
     &lt;18d&gt;   DW_AT_high_pc     : 0x0
     &lt;191&gt;   DW_AT_stmt_list   : 0x0
  
  &lt;1&gt;&lt;195&gt;: Abbrev Number: 2 (DW_TAG_subprogram)
     &lt;196&gt;   DW_AT_name        : (indirect string, offset: 0x704): OK
     &lt;19a&gt;   DW_AT_decl_file   : 0
     &lt;19b&gt;   DW_AT_decl_line   : 0
     &lt;19c&gt;   DW_AT_low_pc      : 0x69050403
     &lt;1a0&gt;   DW_AT_high_pc     : 0x400746e
     &lt;1a4&gt;   DW_AT_frame_base  : 0 byte block:    ()
     &lt;1a5&gt;   DW_AT_sibling     : &lt;0x2000170&gt;
  &lt;2&gt;&lt;1a9&gt;: Abbrev Number: 8020
  </code></pre>
  
  <p>while with readelf</p>
  
  <pre><code>Compilation Unit @ offset 0x170:
    Length:        0x7dc (32-bit)
    Version:       3
    Abbrev Offset: 0xdb
    Pointer Size:  4
  
  &lt;0&gt;&lt;17b&gt;: Abbrev Number: 1 (DW_TAG_compile_unit)   
     &lt;17c&gt;   DW_AT_producer    : (indirect string, offset: 0x3c1): GNU C++ 4.8.1 -mlittle-endian -march=armv7-a -mfpu=vfp -mfloat-abi=softfp -mapcs-frame -mlong-calls -gdwarf-3 -ansi -fno-zero-initialized-in-bss    
     &lt;180&gt;   DW_AT_language    : 4    (C++)
     &lt;181&gt;   DW_AT_name        : (indirect string, offset: 0x192): C:/[...]
     &lt;185&gt;   DW_AT_comp_dir    : (indirect string, offset: 0x452): C:\[...]
     &lt;189&gt;   DW_AT_low_pc      : 0x50
     &lt;18d&gt;   DW_AT_high_pc     : 0x204
     &lt;191&gt;   DW_AT_stmt_list   : 0x4d
  
  &lt;1&gt;&lt;195&gt;: Abbrev Number: 2 (DW_TAG_base_type)
     &lt;196&gt;   DW_AT_byte_size   : 4
     &lt;197&gt;   DW_AT_encoding    : 7    (unsigned)
     &lt;198&gt;   DW_AT_name        : (indirect string, offset: 0x2a0): long unsigned int
  &lt;1&gt;&lt;19c&gt;: Abbrev Number: 3 (DW_TAG_base_type)
  </code></pre>
  
  <p>In the second compilation unit, ObjDump didn't change the <em>abbrev Offset</em> and therefore it is using the abbrev numbers from the first compilation unity. It means it is interpreting the next values as attribues of a different type - where it should be a base type, it reads as a subprogram.</p>
  
  <p>Another important fact is that this firmware has dynamic allocation, unlike all the other ones that worked. </p>
  
  <pre><code>ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          18150404 (bytes into file)
  Flags:                             0x5000000, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         1636
  Section header string table index: 1633
  </code></pre>
  
  <p>I know "objdump sees an ELF file through a BFD filter" while "the readelf program does not link against the BFD library". However, I couldn't find any relation between this and CDT ELF parser, though the problems points in this direction.</p>
  
  <p><strong>Questions</strong></p>
  
  <p>Well, it's a very dense problem with one thing linked to another, so I have a lot of questions. But feel free to answer only one, or half. Or even give me ideas about what to test.</p>
  
  <ul>
  <li>What and why is it happening?</li>
  <li>Can't ObjDump parse relocations(if the problem is there)?</li>
  <li>Does ObjDump and CDT have libraries in common (from gcc maybe)?</li>
  <li>How the readelf parses it's file? Is it possible to replicate it?</li>
  </ul>
  
  <p><strong>Edit</strong></p>
  
  <p>Because it was only with one of my elf files, and a very complex firmware, it is difficult to replicate it into a <em><a href="https://stackoverflow.com/help/mcve">Minimal, Complete, and Verifiable example</a></em>. But if you have an idea how I can give more information, please tell me.</p>