Bug 13310 - ELF symbols are off by one byte in the symbol table
Summary: ELF symbols are off by one byte in the symbol table
Status: RESOLVED NOTABUG
Alias: None
Product: Meta-yocto
Classification: Build System, Metadata & Runtime
Component: meta-yocto (show other bugs)
Version: 2.6.2
Hardware: Other arm
: Medium normal
Target Milestone: 2.8
Assignee: Joshua Watt
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2019-04-27 15:20 UTC by Francis LB
Modified: 2019-05-02 16:29 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments
Simple hello world code used for the test, with commands and output showing the problem. (684 bytes, text/plain)
2019-04-27 15:20 UTC, Francis LB
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francis LB 2019-04-27 15:20:40 UTC
Created attachment 4509 [details]
Simple hello world code used for the test, with commands and output showing the problem.

The address of the .text symbols in the .symtab symbol table of ELF binaries built using the toolchain seem to be off by one byte.

Steps to reproduce:
1. Cross-compile hello.c (see attachment) using the toolchain
2. Use $OBJDUMP (arm-poky-linux-gnueabi-objdump) to find the address of "main"
3. Use readelf to find the address of "main" from symtab

Observation: The address from readelf is 1 byte after the address from $OBJDUMP.

Expectation: Both are expected to be equal. In my case, objdump returns address 0x50c and readelf returns 0x50d.

I'm using the yocto 2.6.2 toolchain, on CentOS7 host and ARM cortex A9 target.

I observed the same behavior with other ELF that I built on the same setup. I had an older Morty toolchain already available and it does not show the problem.

Thanks!
Comment 1 Joshua Watt 2019-05-02 15:48:09 UTC
Hello,

It is possible that the program was being compiled as THUMB code instead of ARM code? The arm ABI uses the least significant bit of a branch target to determine if a function is ARM (bit is cleared) or THUMB (bit is set). This allows code ti interlink seamlessly between ARM and THUMB code, but it also means that all the THUMB symbols in a given ELF file be odd number. Note that the actual code doesn't start at the odd address since the CPU ignore the least significant bit for the purpose of calculating the target address. The arm-poky-linux-gnueabi-objdump program is likely accounting for this when showing you the symbols, while your host readelf (either because it is targeting x86 or because readelf just doesn't account for it) isn't not.

I believe the easiest way to verify this is to check for "-mthumb" in $CFLAGS

If that's the case, than this is expected behaviour and everything is working as it is supposed to.

For reference: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf
Comment 2 Francis LB 2019-05-02 16:29:57 UTC
Hello,

You are right. After inspection, my current toolchain does provide the THUMB flag. When removing it, I see addresses being aligned. We can close this issue.

I was not familiar with this thumb mode. Thank you very much for the explanation and reference.