Why shows readelf on an ARM binary an odd entry point address?

Question

I compiled a C++ HelloWorld on an Odroid-XU3 with gcc/g++ version 4.8.2 and clang version 3.5. I also wrote a C HelloWorld for comparison.

g++ -static -o HelloWorld hello.cc

readelf -h HelloWorld shows the following entry point addresses:

HelloWorld: 0x8be5 HelloClang: 0x8c45 HelloC: 0x88b5

These are odd addresses. Thumb has odd addresses, so has this something to do with Thumb?

Additionally, objdump -lSd HelloWorld shows the _start Symbol at 0x8be4, which looks like the "right" address.

Why show these two tools different addresses?

Answer 1

Yes addresses are odd because they are Thumb functions, which is a simple question, however why two tools report differently to me is a good question.

readelf on purpose doesn't use BFD (unlike objdump) and mostly used to verify other tools against.

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.