tl;dr
cdt elf parser , objdump cannot parse relocatable file, both work executable file. wonder if related.
objdump has wrong abbrev offsets, cdt parser throws bufferunderflowexception
the problem
i'm working eclipse cdt elf parser in order extract variable informations output files. exectuble files, works perfectly. relocatable file, has problems read it, after point.
edit: it seems buffer underflow not problem, consequence of data misinterpretation. still testing see how processing file. i'll post more later
analysis
at first thought dwarf section must corrupted. using objdump, output file incomplete several errors. shows types, wrong abbreviation numbers , offsets.
the log message:
$ c:\mingw\bin\objdump.exe --dwarf %myfile% > %myfile%_objdump.txt
c:\mingw\bin\objdump.exe: warning: die @ offset 0x1a9 refers abbreviation number 8020 not exist c:\mingw\bin\objdump.exe: warning: die @ offset 0x1a9 refers abbreviation number 8020 not exist c:\mingw\bin\objdump.exe: warning: unable load/parse .debug_info section, cannot interpret .debug_loc section. c:\mingw\bin\objdump.exe: warning: unable load/parse .debug_info section, cannot interpret .debug_ranges section. using readelf, however, can read perfectly, sections , symbols. regarding other binaries, readelf , objdump outputs same.
in debug_info objdump have example:
compilation unit @ offset 0x170: length: 0x7dc (32-bit) version: 3 abbrev offset: 0x0 pointer size: 4 <0><17b>: abbrev number: 1 (dw_tag_compile_unit) <17c> dw_at_producer : (indirect string, offset: 0x0): object <180> dw_at_language : 4 (c++) <181> dw_at_name : (indirect string, offset: 0x0): object <185> dw_at_comp_dir : (indirect string, offset: 0x0): object <189> dw_at_low_pc : 0x0 <18d> dw_at_high_pc : 0x0 <191> dw_at_stmt_list : 0x0 <1><195>: abbrev number: 2 (dw_tag_subprogram) <196> dw_at_name : (indirect string, offset: 0x704): ok <19a> dw_at_decl_file : 0 <19b> dw_at_decl_line : 0 <19c> dw_at_low_pc : 0x69050403 <1a0> dw_at_high_pc : 0x400746e <1a4> dw_at_frame_base : 0 byte block: () <1a5> dw_at_sibling : <0x2000170> <2><1a9>: abbrev number: 8020 while readelf
compilation unit @ offset 0x170: length: 0x7dc (32-bit) version: 3 abbrev offset: 0xdb pointer size: 4 <0><17b>: abbrev number: 1 (dw_tag_compile_unit) <17c> 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 <180> dw_at_language : 4 (c++) <181> dw_at_name : (indirect string, offset: 0x192): c:/[...] <185> dw_at_comp_dir : (indirect string, offset: 0x452): c:\[...] <189> dw_at_low_pc : 0x50 <18d> dw_at_high_pc : 0x204 <191> dw_at_stmt_list : 0x4d <1><195>: abbrev number: 2 (dw_tag_base_type) <196> dw_at_byte_size : 4 <197> dw_at_encoding : 7 (unsigned) <198> dw_at_name : (indirect string, offset: 0x2a0): long unsigned int <1><19c>: abbrev number: 3 (dw_tag_base_type) in second compilation unit, objdump didn't change abbrev offset , therefore using abbrev numbers first compilation unity. means interpreting next values attribues of different type - should base type, reads subprogram.
another important fact firmware has dynamic allocation, unlike other ones worked.
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 file) start of section headers: 18150404 (bytes file) flags: 0x5000000, version5 eabi size of 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 i know "objdump sees elf file through bfd filter" while "the readelf program not link against bfd library". however, couldn't find relation between , cdt elf parser, though problems points in direction.
questions
well, it's dense problem 1 thing linked another, have lot of questions. feel free answer one, or half. or give me ideas test.
- what , why happening?
- can't objdump parse relocations(if problem there)?
- does objdump , cdt have libraries in common (from gcc maybe)?
- how readelf parses it's file? possible replicate it?
edit
because 1 of elf files, , complex firmware, difficult replicate minimal, complete, , verifiable example. if have idea how can give more information, please tell me.
Comments
Post a Comment