[avr, patch 0/1] Addendum to PR3124: Don't PROVIDE __flmap_init_label

[avr, patch 0/1] Addendum to PR3124: Don't PROVIDE __flmap_init_label

[Georg-Johann Lay]

Hi Nick,

this patch removes PROVIDE from __flmap_init_label,
which is needed to make the startup code from AVR-LibC work
with versions of Binutils that don't have PR31124: The start
code would weakly define __flmap_init_label, but when Binutils DOES
support PR31124, then we need the correct values, hence no PROVIDE.

If approved, please apply.

Also if it is possible to squeeze this in v2.42, that would be great.

Thanks,

Johann

Re: [avr, patch 0/1] Addendum to PR3124: Don't PROVIDE __flmap_init_label

[Nick Clifton]

Hi Johann,

> this patch removes PROVIDE from __flmap_init_label,

Err, I think that you forgot to attach the patch ...

> which is needed to make the startup code from AVR-LibC work
> with versions of Binutils that don't have PR31124: The start
> code would weakly define __flmap_init_label, but when Binutils DOES
> support PR31124, then we need the correct values, hence no PROVIDE.
> 
> If approved, please apply.
> 
> Also if it is possible to squeeze this in v2.42, that would be great.

Assuming that it is OK for the mainline, then I will also apply it to the 2.42 branch.
But - since the 2.42 release is now out, it will only affect people who check out the
branch, or if we make a 2.42.1 point release...

Cheers
    Nick

[avr, patch 1/1] Addendum to PR31124: Don't PROVIDE __flmap_init_label

[Georg-Johann Lay]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap.

Supply these symbols as computed by the linker scripts, even when there
are weak definitions.

ld/
	PR 31124
	* scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE.

[-- Attachment #2: pr31124-flmap-noprovide.diff --]
[-- Type: text/x-patch, Size: 989 bytes --]

diff --git a/ld/scripttempl/avr.sc b/ld/scripttempl/avr.sc
index 00ff49aacf4..a70c09e29c1 100644
--- a/ld/scripttempl/avr.sc
+++ b/ld/scripttempl/avr.sc
@@ -358,8 +358,8 @@ EOF
 if test -z "${HAVE_FLMAP}" && test -n "${RELOCATING}"; then
     cat <<EOF
 
-PROVIDE (__flmap_init_label = DEFINED(__flmap_noinit_start) ? __flmap_noinit_start : 0) ;
-PROVIDE (__flmap = DEFINED(__flmap) ? __flmap : 0) ;
+__flmap_init_label = DEFINED(__flmap_noinit_start) ? __flmap_noinit_start : 0 ;
+__flmap = DEFINED(__flmap) ? __flmap : 0 ;
 
 EOF
 fi
@@ -368,7 +368,7 @@ if test -n "${HAVE_FLMAP}"; then
     cat <<EOF
 
 ${RELOCATING+
-PROVIDE (__flmap_init_label = DEFINED(__flmap_init_start) ? __flmap_init_start : 0) ;
+__flmap_init_label = DEFINED(__flmap_init_start) ? __flmap_init_start : 0 ;
 /* User can specify position of .rodata in flash (LMA) by supplying
    __RODATA_FLASH_START__ or __flmap, where the former takes precedence. */
 __RODATA_FLASH_START__ = DEFINED(__RODATA_FLASH_START__)

Re: [avr, patch 0/1] Addendum to PR31124: Don't PROVIDE __flmap_init_label

[Georg-Johann Lay]

Am 30.01.24 um 14:44 schrieb Nick Clifton:
> Hi Johann,
> 
>> this patch removes PROVIDE from __flmap_init_label,
> 
> Err, I think that you forgot to attach the patch ...


Hi Nick,

the patch is in a separate e-mail that only contains the commit
message and the patch:

https://sourceware.org/pipermail/binutils/2024-January/132247.html

Thanks,

Johann

>> which is needed to make the startup code from AVR-LibC work
>> with versions of Binutils that don't have PR31124: The start
>> code would weakly define __flmap_init_label, but when Binutils DOES
>> support PR31124, then we need the correct values, hence no PROVIDE.
>>
>> If approved, please apply.
>>
>> Also if it is possible to squeeze this in v2.42, that would be great.
> 
> Assuming that it is OK for the mainline, then I will also apply it to 
> the 2.42 branch.
> But - since the 2.42 release is now out, it will only affect people who 
> check out the
> branch, or if we make a 2.42.1 point release...
> 
> Cheers
>     Nick

Re: [avr, patch 0/1] Addendum to PR31124: Don't PROVIDE __flmap_init_label

[Nick Clifton]

Hi Johann,

> the patch is in a separate e-mail that only contains the commit
> message and the patch:

Sorry - I was a bit slow yesterday.


> https://sourceware.org/pipermail/binutils/2024-January/132247.html

Patch approved and applied, mainline and 2.42 branch.

Cheers
   Nick