[Bug ld/20259] New: Regresion on binary for ARM when targetting Cortex-M, data alignment error

[nathael.pajani at ed3l dot fr]

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.