Parsing Eclipse CDT ELF解析器无法解析调试文件

TL；DR

CDT ELF解析器和ObjDump无法解析我的可重定位文件，但它们都能正确地处理可执行文件。我想知道他们是否有亲戚关系

ObjDump有错误的abbrev偏移量，CDT解析器抛出BufferUnderflowException

问题

我正在使用EclipseCDTELF解析器从输出文件中提取变量信息。对于我的exectuble文件，它可以完美地工作。但对于可重新定位的文件，它在读取时会遇到问题，但只能在某一点之后读取

编辑：缓冲区下溢似乎不是真正的问题，而是数据误解的结果。 仍在测试以查看它是如何处理该文件的。稍后我会发布更多

分析

起初我认为矮人部分一定被破坏了。使用ObjDump时，输出文件不完整，有几个错误。它实际上只显示类型，但缩写号和偏移量错误

日志消息：

$C:\MinGW\bin\objdump.exe--dwarf%MYFILE%>%MYFILE%\u objdump.txt

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.

然而，使用readelf，它可以完美地读取所有的部分和符号。关于其他二进制文件，readelf和objdump输出是相同的

例如，在带有objdump的debug_信息中：

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

我知道“objdump通过BFD过滤器查看ELF文件”，而“readelf程序不与BFD库链接”。然而，我找不到它与CDT ELF解析器之间的任何关系，尽管问题指向这个方向

问题

嗯，这是一个非常密集的问题，一件事和另一件事联系在一起，所以我有很多问题。但请随便回答一个或一半。甚至给我一些关于测试内容的想法

• 发生了什么，为什么
• 无法ObjDump解析重定位（如果存在问题）
• ObjDump和CDT是否有共同的库（可能来自gcc）
• readelf如何解析它的文件？有可能复制它吗

编辑

---

因为它只有我的一个elf文件，而且固件非常复杂，所以很难将它复制到一个系统中。但是，如果您知道我如何提供更多信息，请告诉我。

是否有可能就这一问题达成一致？我很感兴趣，但我没有足够的东西开始。嗨@Jonah graham，我发现很难做一个简单的例子，主要是因为我没有办法在相同的环境中重新编译一个简单的固件。我所做的只是用这些工具的结果来说明，我希望这会有所帮助。遗憾的是，我不太可能完全帮助他们。希望其他人也会这样。如果是我，我会在调试器中同时加载readelf和objdump，以理解为什么它们的看法不同。我从您的示例中注意到的另一点是，您正在为ARM构建，但没有使用特定于ARM的objdump/readelf。使用arm none eabi objcopy（或者在您的案例中称为什么）可能会更幸运，特别是如果它是一个更新的版本。这里有最新的预构建工具。最后，如果您有幸使用最新的objdump，您可能只是在eclipsecdt代码中暴露了一个bug，如果是这样，请提出一个bug

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)

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