Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard
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"],
[]
[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",
["
Office Hours for the GNU Toolchain on 2024-06-27 at 11am EST5EDT.
Office Hours for the GNU Toolchain on 2024-06-27 at 11am EST5EDT. Agenda: * https://gcc.gnu.org/wiki/OfficeHours#Next Meeting Link: * https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6 -- Cheers, Carlos.
[RFC] MAINTAINERS: require a BZ account field
Hi! This comes up in #gcc on IRC every so often, so finally writing an RFC. What? --- I propose that MAINTAINERS be modified to be of the form, adding an extra field for their GCC/sourceware account: Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org Further, that the field must not be blank (-> must have a BZ account; there were/are some without at all)! Why? --- 1) This is tied to whether or not people should use their committer email on Bugzilla or a personal email. A lot of people don't seem to use their committer email (-> no permissions) and end up not closing bugs, so pinskia (and often myself these days) end up doing it for them. 2) It's standard practice to wish to CC the committer of a bisect result - or to CC someone who you know wrote patches on a subject area. Doing this on Bugzilla is challenging when there's no map between committer <-> BZ account. Specifically, there are folks who have git committer+author as joeblo...@example.com (or maybe even coold...@example.com) where the local part of the address has *no relation* to their GCC/sw account, so finding who to CC is difficult without e.g. trawling through gcc-cvs mails or asking overseers for help. Summary --- TL;DR: The proposal is: 1) MAINTAINERS should list a field containing either the gcc.gnu.org email in full, or their gcc username (bikeshedding semi-welcome); 2) It should become a requirement that to be in MAINTAINERS, one must possess a Bugzilla account (ideally using their gcc.gnu.org email). thanks, sam signature.asc Description: PGP signature
Re: [RFC] MAINTAINERS: require a BZ account field
On Mon, 24 Jun 2024 at 22:35, Sam James via Gcc wrote: > > Hi! > > This comes up in #gcc on IRC every so often, so finally > writing an RFC. > > What? > --- > > I propose that MAINTAINERS be modified to be of the form, > adding an extra field for their GCC/sourceware account: >account> > Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org > > Further, that the field must not be blank (-> must have a BZ account; > there were/are some without at all)! > > Why? > --- > > 1) This is tied to whether or not people should use their committer email > on Bugzilla or a personal email. A lot of people don't seem to use their > committer email (-> no permissions) and end up not closing bugs, so > pinskia (and often myself these days) end up doing it for them. > > 2) It's standard practice to wish to CC the committer of a bisect result > - or to CC someone who you know wrote patches on a subject area. Doing > this on Bugzilla is challenging when there's no map between committer > <-> BZ account. > > Specifically, there are folks who have git committer+author as > joeblo...@example.com (or maybe even coold...@example.com) where the > local part of the address has *no relation* to their GCC/sw account, > so finding who to CC is difficult without e.g. trawling through gcc-cvs > mails or asking overseers for help. > > Summary > --- > > TL;DR: The proposal is: > > 1) MAINTAINERS should list a field containing either the gcc.gnu.org > email in full, or their gcc username (bikeshedding semi-welcome); I like the proposal. I'd say it should be fine to just put the gcc username (without the @gcc.gnu.org part) because the lines are long enough already, and repeating the domain on every line is redundant. > > 2) It should become a requirement that to be in MAINTAINERS, one must > possess a Bugzilla account (ideally using their gcc.gnu.org email). > > thanks, > sam
Re: [RFC] MAINTAINERS: require a BZ account field
Hi, Sam James via Gcc writes: > Hi! > > This comes up in #gcc on IRC every so often, so finally > writing an RFC. > > What? > --- > > I propose that MAINTAINERS be modified to be of the form, > adding an extra field for their GCC/sourceware account: >account> > Joe Bloggsjoeblo...@example.com jblo...@gcc.gnu.org > > Further, that the field must not be blank (-> must have a BZ account; > there were/are some without at all)! > > Why? > --- > > 1) This is tied to whether or not people should use their committer email > on Bugzilla or a personal email. A lot of people don't seem to use their > committer email (-> no permissions) and end up not closing bugs, so > pinskia (and often myself these days) end up doing it for them. > > 2) It's standard practice to wish to CC the committer of a bisect result > - or to CC someone who you know wrote patches on a subject area. Doing > this on Bugzilla is challenging when there's no map between committer > <-> BZ account. > > Specifically, there are folks who have git committer+author as > joeblo...@example.com (or maybe even coold...@example.com) where the > local part of the address has *no relation* to their GCC/sw account, > so finding who to CC is difficult without e.g. trawling through gcc-cvs > mails or asking overseers for help. I was also proposing (and would like to re-air that here) enforcing that the committer field of each commit is a (valid) @gcc.gnu.org email. This can be configured repo-locally via: $ git config committer.email @gcc.gnu.org Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d (v2.22.0). This makes a permanent association of each commit to its authors Sourceware account. This should not inhibit pushes, as the committer should be a reflection of who /applied/ a patch, and anyone applying a patch that can also push has a Sourceware account. It also should not inhibit any workflow, as it should be automatic. > Summary > --- > > TL;DR: The proposal is: > > 1) MAINTAINERS should list a field containing either the gcc.gnu.org > email in full, or their gcc username (bikeshedding semi-welcome); > > 2) It should become a requirement that to be in MAINTAINERS, one must > possess a Bugzilla account (ideally using their gcc.gnu.org email). -- Arsen Arsenović signature.asc Description: PGP signature
