https://sourceware.org/bugzilla/show_bug.cgi?id=31321
Bug ID: 31321 Summary: AVR: Remove PROVIDE from definition of symbol __flmap_init_label Product: binutils Version: 2.42 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: gjl at gcc dot gnu.org Target Milestone: --- 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. -- You are receiving this mail because: You are on the CC list for the bug.