https://sourceware.org/bugzilla/show_bug.cgi?id=20259
Bug ID: 20259
Summary: Regresion on binary for ARM when targetting Cortex-M,
data alignment error
Product: binutils
Version: 2.26
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: nathael.pajani at ed3l dot fr
Target Milestone: ---
Hi all
I found a regression in binutils 2.26 for arm-none-eabi (2.26-4), also present
in arm-linux-gnueabi (tested on 2.26-4 and 2.26-11) and arm-linux-gnueabihf
(2.26-4 and 2.26-11) when targetting Cortex-M micro-controllers.
When the end of the text section is not aligned on a 32bits boundary then the
following data is shifted in the resulting binary, while it was kept aligned in
previous versions of binutils.
In the following example, end of text section is 00001a8c when using 2.25-5
binutils, and 00001a8b when using 2.26-4 binutils (0x0114 holds the
_end_of_text address for the initial memory copy).
Thus the data in the resulting binary (made by objcopy) is shifted by one byte,
and the memory copy of the data from flash to ram on startup makes inconsistant
copies of data when using word copy.
ELF objdump with 2.25-5 binutils (arm-none-eabi)
---------------------------------------
[....]
114: 00001a8c andeq r1, r0, ip, lsl #21
[....]
00001a84 <status_led_green>:
1a84: 00000401 andeq r0, r0, r1, lsl #8
00001a88 <status_led_red>:
1a88: 00000501 andeq r0, r0, r1, lsl #10
Disassembly of section .data:
10000000 <_start_data>:
10000000: 00b71b00 adcseq r1, r7, r0, lsl #22
10000004: 00000100 andeq r0, r0, r0, lsl #2
---------------------------------------
ELF objdump with 2.26-4 binutils (arm-none-eabi)
---------------------------------------
[....]
114: 00001a8b andeq r1, r0, fp, lsl #21
[....]
00001a84 <status_led_green>:
1a84: ff000401 ; <UNDEFINED> instruction: 0xff00040
00001a88 <status_led_red>:
1a88: Address 0x0000000000001a88 is out of bounds.
Disassembly of section .data:
10000000 <_start_data>:
10000000: 00b71b00 adcseq r1, r7, r0, lsl #22
10000004: 00000100 andeq r0, r0, r0, lsl #2
---------------------------------------
hexdump with 2.25-5 binutils (arm-none-eabi)
---------------------------------------
00001a80 00 00 00 00 01 04 00 00 01 05 00 00 00 1b b7 00 |................|
---------------------------------------
hexdump with 2.26-4 binutils (arm-none-eabi)
---------------------------------------
00001a80 00 00 00 00 01 04 00 ff 01 05 00 00 1b b7 00 00 |................|
---------------------------------------
It looks like that variables created in the linker script using "_end_text =
.;" used to be aligned on a 32bits boundary, and are no more aligned in 2.26
binutils
We found two workarounds, but I think this regression should be fixed.
Workaround 1:
Use char* instead of uin32_t* to copy data upon startup, but this is not
efficient on a 32bit core.
Workaround 2:
Add a ". = ALIGN(4);" before the "_end_text = .;" in the linker script.
The second workaround is fine, but any code found on the internet which does
not include one of these workaround will not work anymore when compiled
(linked) using 2.26 and more recent binutils, which makes it a regression.
The example comes from the result of the compilation of the "adc" example code
from this repository :
http://git.techno-innov.fr/?p=modules
Steps to reproduce:
Clone git repository
Checkout at commit 1a207a74cf95d688a980e6252bac02e334440bb2
http://git.techno-innov.fr/?p=modules;a=snapshot;h=1a207a74cf95d688a980e6252bac02e334440bb2;sf=tgz
cd to modules
Check for CROSS_COMPILE in Makefile
cd to apps/base/adc/
make
The resulting elf and binary files will be adc.elf and adc.bin.
Thanks.
Nathael Pajani - ED3L - Techno-Innov
+++
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
