[PATCH] gcsections: add nativesdk-cairo to exclude list

[PATCH] gcsections: add nativesdk-cairo to exclude list

[Christian Eggers]

configure fails with the following error if gcsections is active during
build of nativesdk-cairo:

| checking whether float word ordering is bigendian... unknown
| configure: error:
|
| Unknown float word ordering. You need to manually preset
| ax_cv_c_float_words_bigendian=no (or yes) according to your system.

Signed-off-by: Christian Eggers <ceggers@arri.de>
---
 meta-poky/conf/distro/include/gcsections.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-poky/conf/distro/include/gcsections.inc b/meta-poky/conf/distro/include/gcsections.inc
index 886a005b341d..a1f8651ae9c3 100644
--- a/meta-poky/conf/distro/include/gcsections.inc
+++ b/meta-poky/conf/distro/include/gcsections.inc
@@ -16,6 +16,8 @@ LDFLAGS_SECTION_REMOVAL:pn-grub = ""
 # SDK packages with build problems using sections
 CFLAGS_SECTION_REMOVAL:pn-nativesdk-glibc = ""
 LDFLAGS_SECTION_REMOVAL:pn-nativesdk-glibc = ""
+CFLAGS_SECTION_REMOVAL:pn-nativesdk-cairo = ""
+LDFLAGS_SECTION_REMOVAL:pn-nativesdk-cairo = ""
 CFLAGS_SECTION_REMOVAL:pn-nativesdk-mingw-w64-runtime = ""
 LDFLAGS_SECTION_REMOVAL:pn-nativesdk-mingw-w64-runtime = ""
 CFLAGS_SECTION_REMOVAL:pn-nativesdk-perl = ""
-- 
2.34.1

Re: [poky] [PATCH] gcsections: add nativesdk-cairo to exclude list

[Khem Raj]

On Mon, Feb 14, 2022 at 12:04 AM Christian Eggers <ceggers@arri.de> wrote:
>
> configure fails with the following error if gcsections is active during
> build of nativesdk-cairo:
>
> | checking whether float word ordering is bigendian... unknown
> | configure: error:
> |
> | Unknown float word ordering. You need to manually preset
> | ax_cv_c_float_words_bigendian=no (or yes) according to your system.
>

hmm, this perhaps is a bug in the native toolchain you have
whichever compiler toolchain is being used to compile nativesdk-cairo
see if you can compile and find the string in resulting binary

% cat a.c
double d __attribute__((used)) =
90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
int main() { return 0; }

% gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fdata-sections -ffunction-sections -flto=auto
-flto-partition=none | strings a.out | grep seesnoon

if it prints out
seesnoonGCC: (GNU) ....

then the test is fine. If it does not then there is something wrong there.

I have done this test on gcc 11.1.0 and clang 13.0.1 on my archlinux
host and it worked all ok.




> Signed-off-by: Christian Eggers <ceggers@arri.de>
> ---
>  meta-poky/conf/distro/include/gcsections.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta-poky/conf/distro/include/gcsections.inc b/meta-poky/conf/distro/include/gcsections.inc
> index 886a005b341d..a1f8651ae9c3 100644
> --- a/meta-poky/conf/distro/include/gcsections.inc
> +++ b/meta-poky/conf/distro/include/gcsections.inc
> @@ -16,6 +16,8 @@ LDFLAGS_SECTION_REMOVAL:pn-grub = ""
>  # SDK packages with build problems using sections
>  CFLAGS_SECTION_REMOVAL:pn-nativesdk-glibc = ""
>  LDFLAGS_SECTION_REMOVAL:pn-nativesdk-glibc = ""
> +CFLAGS_SECTION_REMOVAL:pn-nativesdk-cairo = ""
> +LDFLAGS_SECTION_REMOVAL:pn-nativesdk-cairo = ""
>  CFLAGS_SECTION_REMOVAL:pn-nativesdk-mingw-w64-runtime = ""
>  LDFLAGS_SECTION_REMOVAL:pn-nativesdk-mingw-w64-runtime = ""
>  CFLAGS_SECTION_REMOVAL:pn-nativesdk-perl = ""
> --
> 2.34.1
>
>
> 
>

Re: [poky] [PATCH] gcsections: add nativesdk-cairo to exclude list

[Christian Eggers]

On Monday, 14 February 2022, 18:16:57 CET, Khem Raj wrote:
> On Mon, Feb 14, 2022 at 12:04 AM Christian Eggers <ceggers@arri.de> wrote:
> >
> > configure fails with the following error if gcsections is active during
> > build of nativesdk-cairo:
> >
> > | checking whether float word ordering is bigendian... unknown
> > | configure: error:
> > |
> > | Unknown float word ordering. You need to manually preset
> > | ax_cv_c_float_words_bigendian=no (or yes) according to your system.
> >
> 
> hmm, this perhaps is a bug in the native toolchain you have
I thought that nativesdk packages are built by the nativesdk toolchain,
aren't they?

config.log (created without linker GC):
-------------------------8<--------------------------
configure:20976: checking whether float word ordering is bigendian
configure:21005: x86_64-pokysdk-linux-gcc  --sysroot=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot -o conftest  -O2 -g -feliminate-unused-debug-types -pipe -fmacro-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0                      -fdebug-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0                      -fdebug-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot=                      -fdebug-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot-native=    -Wl,-O1  conftest.c  >&5
configure:21005: $? = 0
configure:21025: result: no
-------------------------8<--------------------------

> whichever compiler toolchain is being used to compile nativesdk-cairo
> see if you can compile and find the string in resulting binary
> 
> % cat a.c
> double d __attribute__((used)) =
> 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
> int main() { return 0; }
> 
> % gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -fdata-sections -ffunction-sections -flto=auto
> -flto-partition=none | strings a.out | grep seesnoon
> 
> if it prints out
> seesnoonGCC: (GNU) ....
> 
> then the test is fine. If it does not then there is something wrong there.
I use openSUSE 15.3 with an ancient GCC 7.5.0. It doesn't recognize '-fcf-protection'.

gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall \
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 \
-Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64 \
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection \
-fdata-sections -ffunction-sections -flto=auto \
-flto-partition=none | strings a.out | grep seesnoon

seesnoon
(without GCC: ...)

> 
> I have done this test on gcc 11.1.0 and clang 13.0.1 on my archlinux
> host and it worked all ok.
> 

See also:
https://gitlab.freedesktop.org/cairo/cairo/-/issues/459

Re: [poky] [PATCH] gcsections: add nativesdk-cairo to exclude list

[Khem Raj]

On Mon, Feb 14, 2022 at 9:43 AM Christian Eggers <ceggers@arri.de> wrote:
>
> On Monday, 14 February 2022, 18:16:57 CET, Khem Raj wrote:
> > On Mon, Feb 14, 2022 at 12:04 AM Christian Eggers <ceggers@arri.de> wrote:
> > >
> > > configure fails with the following error if gcsections is active during
> > > build of nativesdk-cairo:
> > >
> > > | checking whether float word ordering is bigendian... unknown
> > > | configure: error:
> > > |
> > > | Unknown float word ordering. You need to manually preset
> > > | ax_cv_c_float_words_bigendian=no (or yes) according to your system.
> > >
> >
> > hmm, this perhaps is a bug in the native toolchain you have
> I thought that nativesdk packages are built by the nativesdk toolchain,
> aren't they?
>

yes they are, I just was not sure which variant you were building.

> config.log (created without linker GC):
> -------------------------8<--------------------------
> configure:20976: checking whether float word ordering is bigendian
> configure:21005: x86_64-pokysdk-linux-gcc  --sysroot=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot -o conftest  -O2 -g -feliminate-unused-debug-types -pipe -fmacro-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0                      -fdebug-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0                      -fdebug-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot=                      -fdebug-prefix-map=/home/eggers/Projekte/jupiter/yocto-warrior/build/devel-honister/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot-native=    -Wl,-O1  conftest.c  >&5
> configure:21005: $? = 0
> configure:21025: result: no
> -------------------------8<--------------------------
>
> > whichever compiler toolchain is being used to compile nativesdk-cairo
> > see if you can compile and find the string in resulting binary
> >
> > % cat a.c
> > double d __attribute__((used)) =
> > 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
> > int main() { return 0; }
> >
> > % gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall
> > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64
> > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> > -fcf-protection -fdata-sections -ffunction-sections -flto=auto
> > -flto-partition=none | strings a.out | grep seesnoon
> >
> > if it prints out
> > seesnoonGCC: (GNU) ....
> >
> > then the test is fine. If it does not then there is something wrong there.
> I use openSUSE 15.3 with an ancient GCC 7.5.0. It doesn't recognize '-fcf-protection'.
>
> gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall \
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 \
> -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64 \
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection \
> -fdata-sections -ffunction-sections -flto=auto \
> -flto-partition=none | strings a.out | grep seesnoon
>
> seesnoon
> (without GCC: ...)

so I wonder why this test fails. Do it on nativesdk-gcc as well.

>
> >
> > I have done this test on gcc 11.1.0 and clang 13.0.1 on my archlinux
> > host and it worked all ok.
> >
>
> See also:
> https://gitlab.freedesktop.org/cairo/cairo/-/issues/459
>
>
>
>

Re: [poky] [PATCH] gcsections: add nativesdk-cairo to exclude list

[Christian Eggers]

On Monday, 14 February 2022, 19:02:35 CET, Khem Raj wrote:
> so I wonder why this test fails. Do it on nativesdk-gcc as well.

I made some test within the devshell of nativesdk-cairo (the compiler command
line is derived from config.log):

# cat conftest.c
double d __attribute__((used)) = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
int main() { return 0; }

# x86_64-pokysdk-linux-gcc  \
    --sysroot=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot
    -o conftest.no-gc  -O2 -g -feliminate-unused-debug-types -pipe 
    -fmacro-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0 \
    -fdebug-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0 \
    -fdebug-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot= \
    -fdebug-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot-native=
    -Wl,-O1  conftest.c

# x86_64-pokysdk-linux-gcc  \
    --sysroot=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot \
    -o conftest.gc  -O2 -g -feliminate-unused-debug-types -pipe \ 
    -fmacro-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0 \
    -fdebug-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0=/usr/src/debug/nativesdk-cairo/1.16.0-r0 \
    -fdebug-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot= \
    -fdebug-prefix-map=/<...>/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-cairo/1.16.0-r0/recipe-sysroot-native=
    -ffunction-sections -fdata-sections  -Wl,-O1  -Wl,--gc-sections conftest.c

# strings conftest.no-gc > conftest.strings.no-gc
# strings conftest.gc > conftest.strings.gc

# diff conftest.strings.no-gc conftest.strings.gc
13c13
< seesnoonGCC: (GNU) 11.2.0
---
> GCC: (GNU) 11.2.0
80c80
< GNU C17 11.2.0 -mtune=generic -march=x86-64 -g -O2 -feliminate-unused-debug-types
---
> GNU C17 11.2.0 -mtune=generic -march=x86-64 -g -O2 -feliminate-unused-debug-types -ffunction-sections -fdata-sections
127d126
< __data_start
130d128
< _IO_stdin_used
155d152
< .rodata


# objdump -s -j .data conftest.no-gc 

conftest.no-gc:     file format elf64-x86-64

Contents of section .data:
 5018 00000000 00000000 20500000 00000000  ........ P......
 5028 73656573 6e6f6f6e                    seesnoon        


# objdump -s -j .data conftest.gc

conftest.gc:     file format elf64-x86-64

Contents of section .data:
 5018 18500000 00000000                    .P......        


When I compile/link with '-ffunction-sections -fdata-sections' but without
"-Wl,--gc-sections", the final .data section contains "seesnoon". So it
looks like the linker is not really impressed by __attribute__((used)).
For me this looks like an attribute for compiling, not linking ...

When I compile without linking ('-c'), the object file also contains
"seesnoon" (in the .data.d section):

# objdump -s -j .data.d conftest.o

Can't get contents for section '.debug_info'.

conftest.o:     file format elf64-x86-64

Contents of section .data.d:
 0000 73656573 6e6f6f6e                    seesnoon


Summary: Linker garbage collection seems to work fine :-)

I have almost no knowledge about autoconf. Would it be possible
to compile this test without linking ('-c') and to analyze the
.o file instead?

Re: [poky] [PATCH] gcsections: add nativesdk-cairo to exclude list

[Christian Eggers]

On Monday, 14 February 2022, 18:16:57 CET, Khem Raj wrote:
> see if you can compile and find the string in resulting binary
> 
> % cat a.c
> double d __attribute__((used)) =
> 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
> int main() { return 0; }
> 
> % gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -fdata-sections -ffunction-sections -flto=auto
> -flto-partition=none | strings a.out | grep seesnoon
> 
> if it prints out
> seesnoonGCC: (GNU) ....
> 
> then the test is fine. If it does not then there is something wrong there.
> 
> I have done this test on gcc 11.1.0 and clang 13.0.1 on my archlinux
> host and it worked all ok.
You forgot to enable garbage collection on the linker (-Wl,--gc-sections).


On Monday, 14 February 2022, 19:59:35 CET, Christian Eggers wrote:
> Summary: Linker garbage collection seems to work fine :-)
> 
> I have almost no knowledge about autoconf. Would it be possible
> to compile this test without linking ('-c') and to analyze the
> .o file instead?

This seems to cause other problems:
https://github.com/freedesktop/cairo/commit/7cfebce152

>  build: Fix float endian configure test when using clang -O4
> 
> When using clang -O4, the compiled test object is output in bitcode
> format rather than as an ELF object, so when we grep the test value from
> the object it fails.  To work around this, go ahead and link the test
> object into an executable, and then grep against this native binary
> instead of the compiler's intermediary object.
> 
> We need to add __attribute__((used)) to ensure the d variable doesn't
> get optimized out during linking, since it's not referenced in the
> test's main().

So how can the compiler ask the linker to keep a section instead of
garbage collecting it?

I had a short look in the possible ELF section flags and found SHF_GNU_RETAIN:

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/elf/common.h#l572
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/obj-elf.c#l902

Compiling conftest.c with -save-temps showed that this flag is not set:

conftest.s
-------------------------------------8<----------------------------------------
        .globl  d
        .section        .data.d,"aw"  <-- "R" (SHF_GNU_RETAIN) is missing
        .align 8
        .type   d, @object
        .size   d, 8
d:
        .long   1936024947
        .long   1852796782
------------------------------------->8----------------------------------------

Google found a quite dirty hack to set the section flag from C code:

https://stackoverflow.com/questions/6252812/what-does-the-aw-flag-in-the-section-attribute-mean

> unsigned int __attribute__((section(".myVarSection,\"aw\",@nobits#"))) myVar;
Note the '#' sign which is used to terminate the assembler command before
GCC inserts its own "aw" flag:
> .section    .myVarSection,"aw",@nobits#,"aw",@progbits

Regarding the float byte ordering test, the following works with
-ffunction-sections + -fdata-sections (for me):

-------------------------------------8<----------------------------------------
double d __attribute__((used,section(".data,\"awR\"#"))) = ... 
int main() { return 0; }
------------------------------------->8----------------------------------------

Looking for other ways to set the section flags from GCC showed that
a new "retain" attribute has recently been added to GCC (included in 11.2.0):

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6347f4a0904fce17eedf5c071be6f3c118680290

> @item retain
> @cindex @code{retain} variable attribute
> For ELF targets that support the GNU or FreeBSD OSABIs, this attribute
> will save the variable from linker garbage collection.  To support
> this behavior, variables that have not been placed in specific sections
> (e.g. by the @code{section} attribute, or the @code{-fdata-sections}
> option), 7515 will be placed in new, unique sections.

Interestingly this text was not added by the commit, it was only moved
from the "used" attribute to the new "retain" attribute. It looks like
that during development of GCC-11, at first the "used" attribute was
assigned for this and later they switched to the new "retain" attribute:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/output.h;h=6fbec038f7a7ddf29f074943611b53210d17c40c


What shall we do with this information now?

Option 1:
don't use linker garbage collection with cairo/nativesdk-cairo (current state)

Option 2:
Set ax_cv_c_float_words_bigendian manually (per platform).

Option 3:
Use the "section" attribute hack above. Would this work with clang?
Is the '#' comment character suitable for all architectures?

Option 4:
Use the new "retain" attribute. Could this be upstreamed? GCC < 11 emits
a warning:
conftest.c:2:1: warning: ‘retain’ attribute directive ignored [-Wattributes]
For hardknott (GCC 10.2.0), we still need another solution.

Re: [poky] [PATCH] gcsections: add nativesdk-cairo to exclude list

[Khem Raj]

On Tue, Feb 15, 2022 at 12:25 AM Christian Eggers <ceggers@arri.de> wrote:
>
> On Monday, 14 February 2022, 18:16:57 CET, Khem Raj wrote:
> > see if you can compile and find the string in resulting binary
> >
> > % cat a.c
> > double d __attribute__((used)) =
> > 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
> > int main() { return 0; }
> >
> > % gcc a.c -O2 -g -grecord-gcc-switches -pipe -Wall
> > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS  -fstack-protector-strong -m64
> > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> > -fcf-protection -fdata-sections -ffunction-sections -flto=auto
> > -flto-partition=none | strings a.out | grep seesnoon
> >
> > if it prints out
> > seesnoonGCC: (GNU) ....
> >
> > then the test is fine. If it does not then there is something wrong there.
> >
> > I have done this test on gcc 11.1.0 and clang 13.0.1 on my archlinux
> > host and it worked all ok.
> You forgot to enable garbage collection on the linker (-Wl,--gc-sections).
>
>
> On Monday, 14 February 2022, 19:59:35 CET, Christian Eggers wrote:
> > Summary: Linker garbage collection seems to work fine :-)
> >
> > I have almost no knowledge about autoconf. Would it be possible
> > to compile this test without linking ('-c') and to analyze the
> > .o file instead?
>
> This seems to cause other problems:
> https://github.com/freedesktop/cairo/commit/7cfebce152
>
> >  build: Fix float endian configure test when using clang -O4
> >
> > When using clang -O4, the compiled test object is output in bitcode
> > format rather than as an ELF object, so when we grep the test value from
> > the object it fails.  To work around this, go ahead and link the test
> > object into an executable, and then grep against this native binary
> > instead of the compiler's intermediary object.
> >
> > We need to add __attribute__((used)) to ensure the d variable doesn't
> > get optimized out during linking, since it's not referenced in the
> > test's main().
>
> So how can the compiler ask the linker to keep a section instead of
> garbage collecting it?
>
> I had a short look in the possible ELF section flags and found SHF_GNU_RETAIN:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=include/elf/common.h#l572
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/obj-elf.c#l902
>
> Compiling conftest.c with -save-temps showed that this flag is not set:
>
> conftest.s
> -------------------------------------8<----------------------------------------
>         .globl  d
>         .section        .data.d,"aw"  <-- "R" (SHF_GNU_RETAIN) is missing
>         .align 8
>         .type   d, @object
>         .size   d, 8
> d:
>         .long   1936024947
>         .long   1852796782
> ------------------------------------->8----------------------------------------
>
> Google found a quite dirty hack to set the section flag from C code:
>
> https://stackoverflow.com/questions/6252812/what-does-the-aw-flag-in-the-section-attribute-mean
>
> > unsigned int __attribute__((section(".myVarSection,\"aw\",@nobits#"))) myVar;
> Note the '#' sign which is used to terminate the assembler command before
> GCC inserts its own "aw" flag:
> > .section    .myVarSection,"aw",@nobits#,"aw",@progbits
>
> Regarding the float byte ordering test, the following works with
> -ffunction-sections + -fdata-sections (for me):
>
> -------------------------------------8<----------------------------------------
> double d __attribute__((used,section(".data,\"awR\"#"))) = ...
> int main() { return 0; }
> ------------------------------------->8----------------------------------------
>
> Looking for other ways to set the section flags from GCC showed that
> a new "retain" attribute has recently been added to GCC (included in 11.2.0):
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6347f4a0904fce17eedf5c071be6f3c118680290
>
> > @item retain
> > @cindex @code{retain} variable attribute
> > For ELF targets that support the GNU or FreeBSD OSABIs, this attribute
> > will save the variable from linker garbage collection.  To support
> > this behavior, variables that have not been placed in specific sections
> > (e.g. by the @code{section} attribute, or the @code{-fdata-sections}
> > option), 7515 will be placed in new, unique sections.
>
> Interestingly this text was not added by the commit, it was only moved
> from the "used" attribute to the new "retain" attribute. It looks like
> that during development of GCC-11, at first the "used" attribute was
> assigned for this and later they switched to the new "retain" attribute:
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/output.h;h=6fbec038f7a7ddf29f074943611b53210d17c40c
>
>
> What shall we do with this information now?
>
> Option 1:
> don't use linker garbage collection with cairo/nativesdk-cairo (current state)
>
> Option 2:
> Set ax_cv_c_float_words_bigendian manually (per platform).
>
> Option 3:
> Use the "section" attribute hack above. Would this work with clang?
> Is the '#' comment character suitable for all architectures?
>
> Option 4:
> Use the new "retain" attribute. Could this be upstreamed? GCC < 11 emits
> a warning:
> conftest.c:2:1: warning: ‘retain’ attribute directive ignored [-Wattributes]
> For hardknott (GCC 10.2.0), we still need another solution.
>

lets use options 1