https://sourceware.org/bugzilla/show_bug.cgi?id=33523
Bug ID: 33523
Summary: msp430-elf-ld: partial linking + data-sections +
static variables: incoherent relocation entries in the
output ELF
Product: binutils
Version: 2.45
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: apal at szofi dot net
Target Milestone: ---
Created attachment 16410
--> https://sourceware.org/bugzilla/attachment.cgi?id=16410&action=edit
Minimal reproducible example for the bug. Tested under Debain, using both
toolchains mentioned in the description.
On MSP430(X) targets, while performing partial linking on objects having static
variables (including static .bss, .rodata and .data), the resulting output ELF
contains invalid relocation (RELA) entries for such variables if the objects
were compiled with -fdata-sections previously and garbage collection was
effective during the partial linking.
The attached minimal reproducible example shows the issue. The 8 possible
outputs of the linker shall be the same. The 8 possible outputs are generated
with the combination of:
- with or without garbage collection;
- static keyword before the globals or omitting static; and
- no partial linking and partial linking
respectvely. However, the last one, when GC is on, globals are static variables
and linking has a partially linked substep, then the resulting ELF (as it can
be seen clearly from the *.disasm) files contains invalid addresses: all
affected variables are put on the same location (i.e. .section + 0 where
.section is .bss, .data or .rodata). The attached example shows it for BSS but
it works also with RODATA and DATA. Both the disassembly and `readelf` output
shows clearly the issue in this last case:
$ readelf -r module-partial.o
Relocation section '.rela.text' at offset 0x184 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend
0000000e 0000020f R_MSP430X_ABS16 00000000 .bss + 0
00000014 0000020f R_MSP430X_ABS16 00000000 .bss + 0
0000001e 0000020f R_MSP430X_ABS16 00000000 .bss + 0
00000024 0000020f R_MSP430X_ABS16 00000000 .bss + 0
00000028 0000020f R_MSP430X_ABS16 00000000 .bss + 0
00000032 0000020f R_MSP430X_ABS16 00000000 .bss + 0
In addition, the output .bss section size is correct, i.e. section size is
computed correctly and have allocated space for all variables, only the RELA
entries points to incorrect place:
$ readelf -t module-partial.o
[Nr] Name
Type Addr Off Size ES Lk Inf Al
Flags
[...]
[ 3] .bss
NOBITS 0000003c 000070 000004 00 0 0 2
[00000003]: WRITE, ALLOC
Size is 4 bytes, as it is expected from the source (2x short types). Correct
relocation entries shall be (and are):
$ readelf -r module-partial.o
Relocation section '.rela.text' at offset 0x184 contains 6 entries:
Offset Info Type Sym.Value Sym. Name + Addend
0000000e 0000020f R_MSP430X_ABS16 00000000 .bss + 0
00000014 0000020f R_MSP430X_ABS16 00000000 .bss + 0
0000001e 0000020f R_MSP430X_ABS16 00000000 .bss + 2
00000024 0000020f R_MSP430X_ABS16 00000000 .bss + 2
00000028 0000020f R_MSP430X_ABS16 00000000 .bss + 0
00000032 0000020f R_MSP430X_ABS16 00000000 .bss + 2
Interestingly, while strings are also located in rodata and behaves like static
objects, those are linked correctly.
Linker versions tested and affected by this bug:
- The official TI MSP430-GCC-OPENSOURCE toolcahin, available from
https://www.ti.com/tool/MSP430-GCC-OPENSOURCE#downloads: GNU ld (Mitto Systems
Limited - msp430-gcc 9.3.1.11) 2.34
- The latest stable binutils, compiled using the AUR configuration provided by
Arch as available from https://aur.archlinux.org/packages/msp430-elf-binutils:
GNU ld (GNU Binutils) 2.45
The similar kind of bug were searched in two other targets, such as RISC-V and
ARM, but those are looks fine and not affected by this bug (the minimal
reproducible example includes also such configuration, see ./compile.sh).
Another targets were not tested and seemingly only MSP430(X) is affected.
As this issue renders the output (finally linked ELFs and therefore hex files
and binary images) completely unusable, the severity was marked "critical".
--
You are receiving this mail because:
You are on the CC list for the bug.
