Bug 31321

Summary: AVR: Remove PROVIDE from definition of symbol __flmap_init_label
Product: binutils Reporter: Georg-Johann Lay <gjl>
Component: ldAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal    
Priority: P3    
Version: 2.42   
Target Milestone: 2.43   
See Also: https://sourceware.org/bugzilla/show_bug.cgi?id=31124
Host: Target: avr
Build: Last reconfirmed:

Description Georg-Johann Lay 2024-01-31 12:03:59 UTC
PR31124 introduced symbol __flmap_init_label as:

PROVIDE (__flmap_init_label = DEFINED(__flmap_init_start) ? __flmap_init_start : 0) ;

for emulations avrxmega2_flmap and avrxmega4_flmap.

The symbol is supposed to be used by the startup-code crt*.o from AVR-LibC: The symbol resolves to:

* __flmap_init_start when NVMCTRL_CTRLB.FLMAP should be initialized according to __flmap_value_with_lock, which is the case for emulations avrxmega2/4_flmap.

* __flmap_noinit_start when the startup code should bypass the initialization of NVMCTRL_CTRLB.FLMAP, which is the case for emulations avrxmega2/4.

All this works as expected, except in the case when such a crt*.o is used with a version of Binutils that does not implement PR31124.  This can happen when crt*.o is deployed as part of a device pack that's build with PR31124 but used with a toolchain that does not have PR31124.  In such a case, linking will throw an undefined reference to __flmap_init_label.

The obvious fix would be to provide a default for that symbol in gcrt1.S like:

.weak __flmap_init_label
.set  __flmap_init_label, __flmap_noinit_start

which solves the undefined reference, however __flmap_init_label ceases to work when PR31124 *IS* supported, because the PROVIDE (__flmap_init_label = __flmap_init_start) won't touch the already defined __flmap_init_label, hence init of NVMCTRL_CTRLB.FLMAP would be bypassed when it must not be bypassed.

Hence, remove PROVIDE from __flmap_init_label.