gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Sebastian Huber]

Hello,

I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb 
-march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is 
built like this:

make[4]: Entering directory 
'/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb 
-march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh" 
"GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd 
-mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd 
-mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2 
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -mthumb -march=armv7-a+simd 
-mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native" 
"TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard" 
"libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" 
"toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" 
"objext=.o" "prefix=/tmp/sh/i-arm-rtems6" 
"exeext=.exeext.should.not.be.used " 
'CC=the.host.compiler.should.not.be.needed' 
"GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc 
-B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc 
-B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem 
/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem 
/home/EB/sebastian_h/src/gcc/newlib/libc/include 
-B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ 
-B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem 
/tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem 
/tmp/sh/i-arm-rtems6/arm-rtems6/sys-include   " "CFLAGS=-g -O2  -mthumb 
-march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons

When I try to link a test application I get this error:

arm-rtems7-gnatlink 
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali 
testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T 
linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts 
-Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb 
-march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections 
-L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start 
-L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o 
/tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
/opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9: 
sorry, unimplemented: Thumb-1 'hard-float' VFP ABI

The s-secsta.ads seems to be from the right multilib directory 
(Thumb-2), however, I get a sorry message related to Thumb-1?

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Joel Sherrill]

On Thu, Apr 28, 2022, 3:17 AM Sebastian Huber <
sebastian.huber@embedded-brains.de> wrote:

> Hello,
>
> I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb
> -march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is
> built like this:
>
> make[4]: Entering directory
> '/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
> make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb
> -march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh"
> "GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd
> -mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd
> -mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2
> -fexceptions -DIN_RTS -DHAVE_GETIPINFO  -mthumb -march=armv7-a+simd
> -mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native"
> "TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard"
> "libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard"
>
> "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib"
>
> "objext=.o" "prefix=/tmp/sh/i-arm-rtems6"
> "exeext=.exeext.should.not.be.used "
> 'CC=the.host.compiler.should.not.be.needed'
> "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc
> -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc
> -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem
> /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem
> /home/EB/sebastian_h/src/gcc/newlib/libc/include
> -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/
> -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem
> /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem
> /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include   " "CFLAGS=-g -O2  -mthumb
> -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
>
> When I try to link a test application I get this error:
>
> arm-rtems7-gnatlink
> /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali
>
> testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T
> linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts
> -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb
> -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections
> -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start
> -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o
> /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
> /opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9:
>
> sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
>
> The s-secsta.ads seems to be from the right multilib directory
> (Thumb-2), however, I get a sorry message related to Thumb-1?
>

Any chance you can see in the tools build log how that file is actually
compiled?

I'm suspicious that this multilib is named in a complicated way and their
command line parsing doesn't get it all the way through the layers. Years
ago I added -Gn support to this process so they could handle the MIPS for
RTEMS.

What would have to be stripped off of the arts to result in this?

--joel


> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Richard Earnshaw]

On 28/04/2022 09:16, Sebastian Huber wrote:
> /opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9: 
> sorry, unimplemented: Thumb-1 'hard-float' VFP ABI

Does that source file somehow attempt to change the architecture on that 
line?  This looks like something equivalent to a pragma changing things.

R.

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Sebastian Huber]

On 28.04.22 10:16, Sebastian Huber wrote:
> Hello,
> 
> I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb 
> -march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is 
> built like this:
> 
> make[4]: Entering directory 
> '/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
> make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb 
> -march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh" 
> "GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd 
> -mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd 
> -mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2 
> -fexceptions -DIN_RTS -DHAVE_GETIPINFO  -mthumb -march=armv7-a+simd 
> -mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native" 
> "TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard" 
> "libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include   " "CFLAGS=-g -O2  -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
> 
> When I try to link a test application I get this error:
> 
> arm-rtems7-gnatlink 
> /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
> /opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9: sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
> 
> The s-secsta.ads seems to be from the right multilib directory 
> (Thumb-2), however, I get a sorry message related to Thumb-1?

I tried it again with GCC 13, but the problem still exists. I tried to 
use strace to get some more insights (the environment variables are 
partially shown):

[pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", 
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D", 
"testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs", 
"-Icpukit/include/adainclude", 
"-I../../../../src/rtems/cpukit/include/adainclude", 
"-Itestsuites/ada/support", 
"-I../../../../src/rtems/testsuites/ada/support", "-cargs", 
"-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", 
"-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o", 
"-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.", 
"-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a", 
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
"-Wl,--gc-sections", 
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start", 
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-margs", 
"-a", 
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb", 
"-o", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], 
[] <unfinished ...>

[pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", 
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a", "-mthumb", 
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-march=armv7-a", 
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
"-print-multi-directory"], []) = 0

The above call is used to get the multi-lib directory. Which yields:

--RTS=thumb/armv7-a+simd/hard

The flags seem to be obtained by getting all "-m" flags from the 
previous "-cargs" and "-largs". So, each flags appears twice.

[pid 110914] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind", 
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind", 
"-aO/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20", 
"-Mgnat_main", "-Icpukit/include/adainclude", 
"-I../../../../src/rtems/cpukit/include/adainclude", 
"-Itestsuites/ada/support", 
"-I../../../../src/rtems/testsuites/ada/support", 
"--RTS=thumb/armv7-a+simd/hard", "-x", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali"], 
[]) = 0

[pid 110915] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatlink", 
["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatlink", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali", 
"testsuites/ada/tmtests/tm20/init.o", "-Wl,--wrap=printf", 
"-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.", "-lrtemscpu", 
"-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a", "-mthumb", 
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
"-Wl,--gc-sections", 
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start", 
"-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-o", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], 
[]) = 0

Now the trouble starts, there is no longer a "-march=armv7-a" option:

[pid 110916] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", 
["/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", "-c", "-mthumb", 
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
"--RTS=thumb/armv7-a+simd/hard", "-gnatA", "-gnatWb", "-gnatiw", 
"-gnatws", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/b~tm20.adb"], 
[]) = 0

Here a "-march=armv4t" pops up.

[pid 110917] 
execve("/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", 
["/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", "-quiet", 
"-dumpbase", "b~tm20.adb", "-dumpbase-ext", ".adb", "-mthumb", 
"-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
"-fRTS=thumb/armv7-a+simd/hard", "-gnatA", "-gnatWb", "-gnatiw", 
"-gnatws", "-mcpu=arm7tdmi", "-mlibarch=armv4t", "-march=armv4t", 
"-ftls-model=local-exec", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/b~tm20.adb", 
"-o", "/tmp/ccZhtzF7.s"], 
["COLLECT_GCC=/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", 
"COLLECT_GCC_OPTIONS='-c' '-mthumb' '-mfpu=neon' '-mfloat-abi=hard' 
'-mtune=cortex-a9' '-fRTS=thumb/armv7-a+simd/hard' '-gnatA' '-gnatWb' 
'-gnatiw' '-gnatws' '-mcpu=arm7tdmi' '-mlibarch=armv4t' 
'-march=armv4t'"] <unfinished ...>

Could someone give me a hint which component in GCC does this kind of 
option processing and mapping?

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Sebastian Huber]

On 24.06.24 16:06, Sebastian Huber wrote:
> On 28.04.22 10:16, Sebastian Huber wrote:
>> Hello,
>>
>> I test currently the Ada support for RTEMS in GCC 12. We have a 
>> -mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the 
>> Ada RTS is built like this:
>>
>> make[4]: Entering directory 
>> '/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
>> make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb 
>> -march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh" 
>> "GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd 
>> -mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd 
>> -mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2 
>> -fexceptions -DIN_RTS -DHAVE_GETIPINFO  -mthumb -march=armv7-a+simd 
>> -mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native" 
>> "TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard" 
>> "libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include   " "CFLAGS=-g -O2  -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
>>
>> When I try to link a test application I get this error:
>>
>> arm-rtems7-gnatlink 
>> /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
>> /opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9: sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
>>
>> The s-secsta.ads seems to be from the right multilib directory 
>> (Thumb-2), however, I get a sorry message related to Thumb-1?
> 
> I tried it again with GCC 13, but the problem still exists. I tried to 
> use strace to get some more insights (the environment variables are 
> partially shown):
> 
> [pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", 
> ["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D", 
> "testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs", 
> "-Icpukit/include/adainclude", 
> "-I../../../../src/rtems/cpukit/include/adainclude", 
> "-Itestsuites/ada/support", 
> "-I../../../../src/rtems/testsuites/ada/support", "-cargs", 
> "-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", 
> "-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o", 
> "-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.", 
> "-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a", 
> "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
> "-Wl,--gc-sections", 
> "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start", 
> "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-margs", 
> "-a", 
> "/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb", 
> "-o", 
> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], [] <unfinished ...>
> 
> [pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", 
> ["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a", "-mthumb", 
> "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-march=armv7-a", 
> "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
> "-print-multi-directory"], []) = 0
> 
> The above call is used to get the multi-lib directory. Which yields:
> 
> --RTS=thumb/armv7-a+simd/hard
> 
> The flags seem to be obtained by getting all "-m" flags from the 
> previous "-cargs" and "-largs". So, each flags appears twice.
> 
> [pid 110914] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind", 
> ["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind", 
> "-aO/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20", "-Mgnat_main", "-Icpukit/include/adainclude", "-I../../../../src/rtems/cpukit/include/adainclude", "-Itestsuites/ada/support", "-I../../../../src/rtems/testsuites/ada/support", "--RTS=thumb/armv7-a+simd/hard", "-x", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali"], []) = 0
> 
> [pid 110915] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatlink", 
> ["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatlink", 
> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali", "testsuites/ada/tmtests/tm20/init.o", "-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.", "-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-Wl,--gc-sections", "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start", "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-o", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], []) = 0
> 
> Now the trouble starts, there is no longer a "-march=armv7-a" option:
> 
> [pid 110916] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", 
> ["/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", "-c", "-mthumb", 
> "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
> "--RTS=thumb/armv7-a+simd/hard", "-gnatA", "-gnatWb", "-gnatiw", 
> "-gnatws", 
> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/b~tm20.adb"], []) = 0
> 
> Here a "-march=armv4t" pops up.
> 
> [pid 110917] 
> execve("/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", 
> ["/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", "-quiet", 
> "-dumpbase", "b~tm20.adb", "-dumpbase-ext", ".adb", "-mthumb", 
> "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
> "-fRTS=thumb/armv7-a+simd/hard", "-gnatA", "-gnatWb", "-gnatiw", 
> "-gnatws", "-mcpu=arm7tdmi", "-mlibarch=armv4t", "-march=armv4t", 
> "-ftls-model=local-exec", 
> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/b~tm20.adb", "-o", "/tmp/ccZhtzF7.s"], ["COLLECT_GCC=/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", "COLLECT_GCC_OPTIONS='-c' '-mthumb' '-mfpu=neon' '-mfloat-abi=hard' '-mtune=cortex-a9' '-fRTS=thumb/armv7-a+simd/hard' '-gnatA' '-gnatWb' '-gnatiw' '-gnatws' '-mcpu=arm7tdmi' '-mlibarch=armv4t' '-march=armv4t'"] <unfinished ...>
> 
> Could someone give me a hint which component in GCC does this kind of 
> option processing and mapping?

It looks like the bogus options are loaded from a ALI file. The ALI file 
is produced by:

[pid 129509] 
execve("/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", 
["/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", "-I", 
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm21/", "-I", 
"cpukit/include/adainclude", "-I", 
"../../../../src/rtems/cpukit/include/adainclude", "-I", 
"testsuites/ada/support", "-I", 
"../../../../src/rtems/testsuites/ada/support", "-I", "-", "-quiet", 
"-dumpdir", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/", 
"-dumpbase", "tm21.adb", "-dumpbase-ext", ".adb", "-gnatez", "-gnatea", 
"-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
"-fRTS=thumb/armv7-a+simd/hard", "-gnatez", "-mlibarch=armv7-a+simd", 
"-march=armv7-a+simd", "-ftls-model=local-exec", "-gnatO", 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.o", 
"/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm21/tm21.adb", 
"-o", "/tmp/ccK4c8JY.s"], [..., 
"COLLECT_GCC=/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", 
"COLLECT_GCC_OPTIONS='-gnatea' '-c' '-I' 
'/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm21/' '-I' 
'cpukit/include/adainclude' '-I' 
'../../../../src/rtems/cpukit/include/adainclude' '-I' 
'testsuites/ada/support' '-I' 
'../../../../src/rtems/testsuites/ada/support'  '-mthumb' '-mfpu=neon' 
'-mfloat-abi=hard' '-mtune=cortex-a9' '-fRTS=thumb/armv7-a+simd/hard' 
'-I' '-' '-o' 
'/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.o' 
'-gnatez' '-mlibarch=armv7-a+simd' '-march=armv7-a+simd' '-dumpdir' 
'/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/'"] 
<unfinished ...>

This command has all the required options. It writes an ALI file:

[pid 129509] 
unlink("/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.ali") 
= -1 ENOENT (No such file or directory)
[pid 129509] openat(AT_FDCWD, 
"/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.ali", 
O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4

In this file not all required machine options are stored:

head 
/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.ali
V "GNAT Lib v13"
M P W=b
A -mthumb
A -mfpu=neon
A -mfloat-abi=hard
A -mtune=cortex-a9
A --RTS=thumb/armv7-a+simd/hard
P ZX

RN

The "-march=armv7-a+simd" is missing.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Sebastian Huber]

On 25.06.24 14:53, Sebastian Huber wrote:
> On 24.06.24 16:06, Sebastian Huber wrote:
>> On 28.04.22 10:16, Sebastian Huber wrote:
>>> Hello,
>>>
>>> I test currently the Ada support for RTEMS in GCC 12. We have a 
>>> -mthumb -march=armv7-a+simd -mfloat-abi=hard multilib for which the 
>>> Ada RTS is built like this:
>>>
>>> make[4]: Entering directory 
>>> '/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/thumb/armv7-a+simd/hard/libada'
>>> make -C ../../../../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=-mthumb 
>>> -march=armv7-a+simd -mfloat-abi=hard" "LN_S=ln -s" "SHELL=/bin/sh" 
>>> "GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc -mthumb -march=armv7-a+simd 
>>> -mfloat-abi=hard" "GNATLIBCFLAGS=-g -O2 -mthumb -march=armv7-a+simd 
>>> -mfloat-abi=hard" "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -g -O2 
>>> -fexceptions -DIN_RTS -DHAVE_GETIPINFO  -mthumb -march=armv7-a+simd 
>>> -mfloat-abi=hard" "PICFLAG_FOR_TARGET=-fPIC" "THREAD_KIND=native" 
>>> "TRACE=no" "MULTISUBDIR=/thumb/armv7-a+simd/hard" 
>>> "libsubdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard" "toolexeclibdir=/tmp/sh/i-arm-rtems6/lib64/gcc/arm-rtems6/12.0.1/thumb/armv7-a+simd/hard/adalib" "objext=.o" "prefix=/tmp/sh/i-arm-rtems6" "exeext=.exeext.should.not.be.used " 'CC=the.host.compiler.should.not.be.needed' "GCC_FOR_TARGET=/tmp/sh/b-gcc-arm-rtems6/./gcc/xgcc -B/tmp/sh/b-gcc-arm-rtems6/./gcc/ -nostdinc -B/tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/ -isystem /tmp/sh/b-gcc-arm-rtems6/arm-rtems6/newlib/targ-include -isystem /home/EB/sebastian_h/src/gcc/newlib/libc/include -B/tmp/sh/i-arm-rtems6/arm-rtems6/bin/ -B/tmp/sh/i-arm-rtems6/arm-rtems6/lib/ -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/include -isystem /tmp/sh/i-arm-rtems6/arm-rtems6/sys-include   " "CFLAGS=-g -O2  -mthumb -march=armv7-a+simd -mfloat-abi=hard" ./bldtools/oscons/xoscons
>>>
>>> When I try to link a test application I get this error:
>>>
>>> arm-rtems7-gnatlink 
>>> /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/samples/nsecs/nsecs.ali testsuites/ada/samples/nsecs/init.o -qnolinkcmds -T linkcmds.realview_pbx_a9_qemu -Wl,--wrap=printf -Wl,--wrap=puts -Wl,--wrap=putchar -L. -lrtemscpu -lrtemsbsp -lrtemstest -qrtems -mthumb -march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 -Wl,--gc-sections -L/home/EB/sebastian_h/src/rtems/bsps/arm/shared/start -L/home/EB/sebastian_h/src/rtems/bsps/arm/realview-pbx-a9/start -o /tmp/sh/b-rtems/arm/realview_pbx_a9_qemu/testsuites/ada/ada_nsecs.exe
>>> /opt/rtems/7/lib/gcc/arm-rtems7/12.0.1/thumb/armv7-a+simd/hard/adainclude/s-secsta.ads:288:9: sorry, unimplemented: Thumb-1 'hard-float' VFP ABI
>>>
>>> The s-secsta.ads seems to be from the right multilib directory 
>>> (Thumb-2), however, I get a sorry message related to Thumb-1?
>>
>> I tried it again with GCC 13, but the problem still exists. I tried to 
>> use strace to get some more insights (the environment variables are 
>> partially shown):
>>
>> [pid 110912] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", 
>> ["/opt/rtems-6-zynq-1/bin/arm-rtems6-gnatmake", "-D", 
>> "testsuites/ada/tmtests/tm20", "-bargs", "-Mgnat_main", "-margs", 
>> "-Icpukit/include/adainclude", 
>> "-I../../../../src/rtems/cpukit/include/adainclude", 
>> "-Itestsuites/ada/support", 
>> "-I../../../../src/rtems/testsuites/ada/support", "-cargs", 
>> "-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", 
>> "-mtune=cortex-a9", "-largs", "testsuites/ada/tmtests/tm20/init.o", 
>> "-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.", 
>> "-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", 
>> "-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", 
>> "-mtune=cortex-a9", "-Wl,--gc-sections", 
>> "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start", 
>> "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", 
>> "-margs", "-a", 
>> "/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm20/tm20.adb", 
>> "-o", 
>> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], [] <unfinished ...>
>>
>> [pid 110913] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", 
>> ["/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "-march=armv7-a", 
>> "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
>> "-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", 
>> "-mtune=cortex-a9", "-print-multi-directory"], []) = 0
>>
>> The above call is used to get the multi-lib directory. Which yields:
>>
>> --RTS=thumb/armv7-a+simd/hard
>>
>> The flags seem to be obtained by getting all "-m" flags from the 
>> previous "-cargs" and "-largs". So, each flags appears twice.
>>
>> [pid 110914] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind", 
>> ["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatbind", 
>> "-aO/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20", "-Mgnat_main", "-Icpukit/include/adainclude", "-I../../../../src/rtems/cpukit/include/adainclude", "-Itestsuites/ada/support", "-I../../../../src/rtems/testsuites/ada/support", "--RTS=thumb/armv7-a+simd/hard", "-x", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali"], []) = 0
>>
>> [pid 110915] execve("/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatlink", 
>> ["/opt/rtems-6-zynq-1//bin/arm-rtems6-gnatlink", 
>> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm20/tm20.ali", "testsuites/ada/tmtests/tm20/init.o", "-Wl,--wrap=printf", "-Wl,--wrap=puts", "-Wl,--wrap=putchar", "-L.", "-lrtemscpu", "-lrtemsbsp", "-lrtemstest", "-qrtems", "-march=armv7-a", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-Wl,--gc-sections", "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/shared/start", "-L/opt/rtems-6-zynq-1/src/rtems/bsps/arm/xilinx-zynq/start", "-o", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/ada_tm20.exe"], []) = 0
>>
>> Now the trouble starts, there is no longer a "-march=armv7-a" option:
>>
>> [pid 110916] execve("/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", 
>> ["/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", "-c", "-mthumb", 
>> "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
>> "--RTS=thumb/armv7-a+simd/hard", "-gnatA", "-gnatWb", "-gnatiw", 
>> "-gnatws", 
>> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/b~tm20.adb"], []) = 0
>>
>> Here a "-march=armv4t" pops up.
>>
>> [pid 110917] 
>> execve("/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", 
>> ["/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", "-quiet", 
>> "-dumpbase", "b~tm20.adb", "-dumpbase-ext", ".adb", "-mthumb", 
>> "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", 
>> "-fRTS=thumb/armv7-a+simd/hard", "-gnatA", "-gnatWb", "-gnatiw", 
>> "-gnatws", "-mcpu=arm7tdmi", "-mlibarch=armv4t", "-march=armv4t", 
>> "-ftls-model=local-exec", 
>> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/b~tm20.adb", "-o", "/tmp/ccZhtzF7.s"], ["COLLECT_GCC=/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc", "COLLECT_GCC_OPTIONS='-c' '-mthumb' '-mfpu=neon' '-mfloat-abi=hard' '-mtune=cortex-a9' '-fRTS=thumb/armv7-a+simd/hard' '-gnatA' '-gnatWb' '-gnatiw' '-gnatws' '-mcpu=arm7tdmi' '-mlibarch=armv4t' '-march=armv4t'"] <unfinished ...>
>>
>> Could someone give me a hint which component in GCC does this kind of 
>> option processing and mapping?
> 
> It looks like the bogus options are loaded from a ALI file. The ALI file 
> is produced by:
> 
> [pid 129509] 
> execve("/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", 
> ["/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", "-I", 
> "/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm21/", "-I", 
> "cpukit/include/adainclude", "-I", 
> "../../../../src/rtems/cpukit/include/adainclude", "-I", 
> "testsuites/ada/support", "-I", 
> "../../../../src/rtems/testsuites/ada/support", "-I", "-", "-quiet", 
> "-dumpdir", 
> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/", "-dumpbase", "tm21.adb", "-dumpbase-ext", ".adb", "-gnatez", "-gnatea", "-mthumb", "-mfpu=neon", "-mfloat-abi=hard", "-mtune=cortex-a9", "-fRTS=thumb/armv7-a+simd/hard", "-gnatez", "-mlibarch=armv7-a+simd", "-march=armv7-a+simd", "-ftls-model=local-exec", "-gnatO", "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.o", "/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm21/tm21.adb", "-o", "/tmp/ccK4c8JY.s"], [..., "COLLECT_GCC=/opt/rtems-6-zynq-1//bin/arm-rtems6-gcc", "COLLECT_GCC_OPTIONS='-gnatea' '-c' '-I' '/opt/rtems-6-zynq-1/src/rtems/testsuites/ada/tmtests/tm21/' '-I' 'cpukit/include/adainclude' '-I' '../../../../src/rtems/cpukit/include/adainclude' '-I' 'testsuites/ada/support' '-I' '../../../../src/rtems/testsuites/ada/support'  '-mthumb' '-mfpu=neon' '-mfloat-abi=hard' '-mtune=cortex-a9' '-fRTS=thumb/armv7-a+simd/hard' '-I' '-' '-o' '/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.o' '-gnatez' '-mlibarch=armv7-a+simd' '-march=armv7-a+simd' '-dumpdir' '/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/'"] <unfinished ...>
> 
> This command has all the required options. It writes an ALI file:
> 
> [pid 129509] 
> unlink("/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.ali") = -1 ENOENT (No such file or directory)
> [pid 129509] openat(AT_FDCWD, 
> "/opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.ali", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
> 
> In this file not all required machine options are stored:
> 
> head 
> /opt/rtems-6-zynq-1/build/arm-xilinx_zynq_zc702-bsp-extra/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.ali
> V "GNAT Lib v13"
> M P W=b
> A -mthumb
> A -mfpu=neon
> A -mfloat-abi=hard
> A -mtune=cortex-a9
> A --RTS=thumb/armv7-a+simd/hard
> P ZX
> 
> RN
> 
> The "-march=armv7-a+simd" is missing.

Ok, I think the error is somewhere in the GCC main program. For this 
command line:

/opt/rtems-6-zynq-1/bin/arm-rtems6-gcc -gnatea -c 
-I/home/EB/sebastian_h/src/rtems/testsuites/ada/tmtests/tm21/ 
-Icpukit/include/adainclude 
-I/home/EB/sebastian_h/src/rtems/cpukit/include/adainclude 
-Itestsuites/ada/support 
-I/home/EB/sebastian_h/src/rtems/testsuites/ada/support -mthumb 
-march=armv7-a+simd -mfloat-abi=hard -mtune=cortex-a9 
--RTS=thumb/armv7-a+simd/hard -I- -o 
/tmp/sh/b-rtems/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.o 
/home/EB/sebastian_h/src/rtems/testsuites/ada/tmtests/tm21/tm21.adb -gnatez

The options are converted for gnat1 like this:

Breakpoint 3, pex_run_in_environment (obj=0x5ee660, flags=1, 
executable=0x5ec350 
"/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", argv=0x5ee1e8,
     env=env@entry=0x0, orig_outname=0x0, errname=0x0, 
err=0x7fffffffd0ec) at 
/opt/rtems-6-zynq-1/src/gcc/libiberty/pex-common.c:156
156     {
(gdb) p *argv@40
$11 = {0x5ec350 "/opt/rtems-6-zynq-1/lib/gcc/arm-rtems6/13.2.1/gnat1", 
0x5e8540 "-I", 0x5e8550 
"/home/EB/sebastian_h/src/rtems/testsuites/ada/tmtests/tm21/",
   0x5e8590 "-I", 0x5e85a0 "cpukit/include/adainclude", 0x5e85c0 "-I", 
0x5e85d0 "/home/EB/sebastian_h/src/rtems/cpukit/include/adainclude", 
0x5e8610 "-I",
   0x5e8620 "testsuites/ada/support", 0x5e8640 "-I", 0x5e8650 
"/home/EB/sebastian_h/src/rtems/testsuites/ada/support", 0x5e8690 "-I", 
0x5e86a0 "-", 0x5e86b0 "-quiet",
   0x5e86c0 "-dumpdir", 0x5e86d0 
"/tmp/sh/b-rtems/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/", 
0x5e8720 "-dumpbase", 0x5e8730 "tm21.adb",
   0x5e8740 "-dumpbase-ext", 0x5e8750 ".adb", 0x5e8760 "-gnatez", 
0x5e8770 "-gnatea", 0x5e8780 "-mthumb", 0x5e8790 "-mfloat-abi=hard", 
0x5e87b0 "-mtune=cortex-a9",
   0x5e87d0 "-fRTS=thumb/armv7-a+simd/hard", 0x5e87f0 "-gnatez", 
0x5e8800 "-mlibarch=armv7-a+simd", 0x5e8820 "-march=armv7-a+simd", 
0x5e8840 "-ftls-model=local-exec",
   0x5e8860 "-gnatO", 0x5e8870 
"/tmp/sh/b-rtems/arm/xilinx_zynq_zc702/testsuites/ada/tmtests/tm21/tm21.o",
   0x5e88c0 
"/home/EB/sebastian_h/src/rtems/testsuites/ada/tmtests/tm21/tm21.adb", 
0x5e8910 "-o", 0x5e8920 "/tmp/ccOyyUfd.s", 0x0, 0x0, 0x0, 0x0, 0x0}

Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this 
option is dropped in switch-c.adb and doesn't get added to the ALI file.

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Eric Botcazou]

> Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this 
> option is dropped in switch-c.adb and doesn't get added to the ALI file.

This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h 
and it looks like the '+' character is not matched by '*' or some such.

-- 
Eric Botcazou

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Sebastian Huber]

Hello Eric,

On 26.06.24 01:35, Eric Botcazou wrote:
>> Here, the "-march=armv7-a+simd" was moved after the "-gnatez". So this
>> option is dropped in switch-c.adb and doesn't get added to the ALI file.
> 
> This comes from the spec magic implemented in ada/gcc-interface/lang-specs.h
> and it looks like the '+' character is not matched by '*' or some such.

thanks for the hint. So, maybe the problem is here:

     %{gnatea:-gnatez} %{g*&m*&f*} \

 From the documentation 
(https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):

%{S*}

     Substitutes all the switches specified to GCC whose names start 
with -S, but which also take an argument. This is used for switches like 
-o, -D, -I, etc. GCC considers -o foo as being one switch whose name 
starts with ‘o’. %{o*} substitutes this text, including the space. Thus 
two arguments are generated.

%{S*&T*}

     Like %{S*}, but preserve order of S and T options (the order of S 
and T in the spec is not significant). There can be any number of 
ampersand-separated variables; for each the wild card is optional. 
Useful for CPP as ‘%{D*&U*&A*}’.

It looks like this is working as documented. I checked this with the 
following spec file:

*startfile:
BEGIN %{g*&m*&f*} END

On my x86_64 host GCC, this works fine:

gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub -march=armv7-a+simd

... BEGIN -mfoo=bar+blub -march=armv7-a+simd END ...

On the arm GCC, it looks good also:

arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub 
-march=armv7-a+simd

... BEGIN -mfoo=bar+blub -marm -mlibarch=armv7-a -march=armv7-a END ...

arm-rtems6-gcc -specs=test.spec -wrapper echo main.c -mfoo=bar+blub 
-march=armv7-a+simd -mfloat-abi=hard

... BEGIN -mfoo=bar+blub -mfloat-abi=hard -marm -mlibarch=armv7-a+simd 
-march=armv7-a+simd END ...

-- 
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

[Eric Botcazou]

>  From the documentation
> (https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html):
> 
> %{S*}
> 
>      Substitutes all the switches specified to GCC whose names start
> with -S, but which also take an argument. This is used for switches like
> -o, -D, -I, etc. GCC considers -o foo as being one switch whose name
> starts with ‘o’. %{o*} substitutes this text, including the space. Thus
> two arguments are generated.

The ultimate spec(!) is to be found in gcc.cc though, which says:

 %{S*}	substitutes all the switches specified to GCC whose names start
	with -S.  This is used for -o, -I, etc; switches that take
	arguments.  GCC considers `-o foo' as being one switch whose
	name starts with `o'.  %{o*} would substitute this text,
	including the space; thus, two arguments would be generated

 %{S*&T*}	likewise, but preserve order of S and T options (the order
	of S and T in the spec is not significant).  Can be any number
	of ampersand-separated variables; for each the wild card is
	optional.  Useful for CPP as %{D*&U*&A*}.

> It looks like this is working as documented. I checked this with the
> following spec file:

But you wouldn't have a problem if it was, would you?  What happens if the '+' 
is changed to another character in the line passed to the driver.

-- 
Eric Botcazou