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 +++
Direct access to the linker script used : http://git.techno-innov.fr/?p=modules;a=blob;f=lpc_link_lpc1224.ld;h=b3f567d8f9210b5a7502154696af62d2d7fb8b62;hb=1a207a74cf95d688a980e6252bac02e334440bb2 Thanks. +++
Created attachment 9371 [details] Proposed patch Hi Nathael, Please could you try out this possible patch and let me know if it works for you. Cheers Nick
I think this has been fixed. If not, well, 2.26 is obsolete anyway.