13310 2019-04-27 15:20:40 +0000 ELF symbols are off by one byte in the symbol table 2019-05-02 16:29:57 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 2.6.2 Other arm RESOLVED NOTABUG Medium normal 2.8 1 frlebc JPEWhacker frlebc poky.bs.watcher poky.watcher randy.macleod --- --- No (bug/feature does not impact docs) oldest_to_newest 83664 0 4509 frlebc 2019-04-27 15:20:40 +0000 Created attachment 4509 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! 83709 1 JPEWhacker 2019-05-02 15:48:09 +0000 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 83711 2 frlebc 2019-05-02 16:29:57 +0000 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. 4509 2019-04-27 15:20:40 +0000 2019-04-27 15:20:40 +0000 Simple hello world code used for the test, with commands and output showing the problem. objdump_readelf_results.txt text/plain 684 frlebc aGVsbG8uYzoKI2luY2x1ZGUgPHN0ZGlvLmg+CgppbnQgbWFpbigpIHsKCXByaW50ZigiSGVsbG8g d29ybGQhXG4iKTsKCXJldHVybiAwOwp9CgotLS0tLS0tClt1c2VyQG9zdS1jZW50b3M3IGhlbGxv XSQgc291cmNlIGVudmlyb25tZW50LXNldHVwLWNvcnRleGE5dDJoZi1uZW9uLXBva3ktbGludXgt Z251ZWFiaQpbdXNlckBvc3UtY2VudG9zNyBoZWxsb10kICRDQyBoZWxsby5jIC1vIGhlbGxvClt1 c2VyQG9zdS1jZW50b3M3IGhlbGxvXSQgJE9CSkRVTVAgLS1zeW1zIGhlbGxvIHwgZ3JlcCBtYWlu CjAwMDAwMDAwICAgICAgIEYgKlVORCoJMDAwMDAwMDAgICAgICAgICAgICAgIF9fbGliY19zdGFy dF9tYWluQEBHTElCQ18yLjQKMDAwMDA1MGMgZyAgICAgRiAudGV4dAkwMDAwMDAxOCAgICAgICAg ICAgICAgbWFpbgpbdXNlckBvc3UtY2VudG9zNyBoZWxsb10kIHJlYWRlbGYgLS1zeW1zIGhlbGxv IHwgZ3JlcCBtYWluCiAgICAgNjogMDAwMDAwMDAgICAgIDAgRlVOQyAgICBHTE9CQUwgREVGQVVM VCAgVU5EIF9fbGliY19zdGFydF9tYWluQEdMSUJDXzIuNCAoMikKICAgMTAzOiAwMDAwMDAwMCAg ICAgMCBGVU5DICAgIEdMT0JBTCBERUZBVUxUICBVTkQgX19saWJjX3N0YXJ0X21haW5AQEdMSUJD XwogICAxMTI6IDAwMDAwNTBkICAgIDI0IEZVTkMgICAgR0xPQkFMIERFRkFVTFQgICAxMyBtYWlu