为什么在 ARM 二进制文件上向 readelf 显示奇数入口点地址？
Why shows readelf on an ARM binary an odd entry point address?
我在 Odroid-XU3 上用 gcc/g++ 版本 4.8.2 和 clang 版本 3.5 编译了一个 C++ HelloWorld。我也写了个C的HelloWorld来对比一下
g++ -static -o HelloWorld hello.cc
readelf -h HelloWorld 显示以下入口点地址：
HelloWorld: 0x8be5
HelloClang: 0x8c45
HelloC: 0x88b5
这些是奇数地址。 Thumb 有奇怪的地址，所以这与 Thumb 有关系吗？
此外，objdump -lSd HelloWorld 在 0x8be4 处显示 _start 符号，看起来像 "right" 地址。
为什么这两个工具显示不同的地址？
是的，地址很奇怪，因为它们是 Thumb 函数，这是一个简单的问题，但是为什么两个工具向我报告不同是一个很好的问题。
readelf 故意不使用 BFD（与 objdump 不同），主要用于验证其他工具。
Here:
The difference between readelf and objdump: Both programs are
capable of displaying the contents of ELF format files, so why does
the binutils project have two file dumpers ?
The reason is that
objdump sees an ELF file through a BFD filter of the world; if BFD
has a bug where, say, it disagrees about a machine constant in
e_flags, then the odds are good that it will remain internally
consistent. The linker sees it the BFD way, objdump sees it the BFD
way, GAS sees it the BFD way. There was need for a tool to go find
out what the file actually says.
This is why the readelf program
does not link against the BFD library - it exists as an independent
program to help verify the correct working of BFD.
There is also the
case that readelf can provide more information about an ELF file
than is provided by objdump. In particular it can display DWARF
debugging information which (at the moment) objdump cannot.
我在 Odroid-XU3 上用 gcc/g++ 版本 4.8.2 和 clang 版本 3.5 编译了一个 C++ HelloWorld。我也写了个C的HelloWorld来对比一下
g++ -static -o HelloWorld hello.cc
readelf -h HelloWorld 显示以下入口点地址：
HelloWorld: 0x8be5
HelloClang: 0x8c45
HelloC: 0x88b5
这些是奇数地址。 Thumb 有奇怪的地址，所以这与 Thumb 有关系吗？
此外，objdump -lSd HelloWorld 在 0x8be4 处显示 _start 符号，看起来像 "right" 地址。
为什么这两个工具显示不同的地址？
是的，地址很奇怪，因为它们是 Thumb 函数，这是一个简单的问题，但是为什么两个工具向我报告不同是一个很好的问题。
readelf 故意不使用 BFD（与 objdump 不同），主要用于验证其他工具。
Here:
The difference between readelf and objdump: Both programs are capable of displaying the contents of ELF format files, so why does the binutils project have two file dumpers ?
The reason is that objdump sees an ELF file through a BFD filter of the world; if BFD has a bug where, say, it disagrees about a machine constant in e_flags, then the odds are good that it will remain internally consistent. The linker sees it the BFD way, objdump sees it the BFD way, GAS sees it the BFD way. There was need for a tool to go find out what the file actually says.
This is why the readelf program does not link against the BFD library - it exists as an independent program to help verify the correct working of BFD.
There is also the case that readelf can provide more information about an ELF file than is provided by objdump. In particular it can display DWARF debugging information which (at the moment) objdump cannot.