Re: Building RTEMS 6 toolchain on a Mac
On 4/27/22 08:48, Sebastian Huber wrote: On 27.04.22 08:45, Karel Gardas wrote: On 4/27/22 06:46, Sebastian Huber wrote: On 26.04.22 22:57, Karel Gardas wrote: On 4/25/22 10:10, Sebastian Huber wrote: Hello Heinz, you are probably one of the first persons building GCC 12 on this platform. I checked in a change which could fix the problem. Not sure if this is related, but after this hacking I'm no longer able to build neither 6/rtems-arm not 6/rtems-x86_64. I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest mpfr release and used by the GCC contrib/download_prerequisites script currently. If this version doesn't build on macOS, then it would be good to submit a bug report to mpfr. The problem is that I'm perfectly able to build 4.1.0 including testsuite including its run on catalina. So the problem is somewhere else and rsb logging was just misleading... The RTEMS 7 RSB configuration still uses mpfr-4.1.0 (and GCC 12), maybe you can check it here. I'm a little bit confused since HEAD works fine with 7/rtems-arm and 7/rtems-x86_64 on catalina. So I reverted patches up to: me@mes-MacBook-Pro rtems % git log -1 commit 70f302e08c9053637f5eff7dfb52d3442aaf76cb (HEAD) Author: Chris Johns Date: Tue Apr 26 10:13:41 2022 +1000 gdb: Split python's version into major/minor and check for embed option Closes #4631 and now, 6/rtems-x86_64 correctly fails as I reported, but 7/rtems-x86_64 builds fine again. Diffing shows quite major differences between rtems-default.bset files for 6/ and 7/ so I guess that's the reason... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6? (Can Ada be used?)
On Wed, Apr 27, 2022 at 1:12 PM Frank Kühndel < frank.kuehn...@embedded-brains.de> wrote: > Hi Karel, > > On 4/27/22 19:46, Karel Gardas wrote: > > On 4/27/22 19:25, Frank Kühndel wrote: > >> I do not need ADA but ADA may be worth considering. With GCC 10 one > >> needed to have a GNAT 10 compiler installed to build the tools incl. > >> --with_ada. I presume, one would need a GNAT 12 to build ADA with the > >> GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I > >> know of have GNAT 10 at best (I have not checked on tumbleweed yet). > >> OpenSUSE may get ADA 12 from an unusual repro??? > > > > On https://gcc.gnu.org/install/prerequisites.html there is a text: > > > > " > > GNAT > > > > In order to build GNAT, the Ada compiler, you need a working GNAT > > compiler (GCC version 5.1 or later). > > > > ... > > " > > > > is it outdated? If so, this would require some bugreport to gcc team? > > The text says too: "Other native compiler versions may work but this is > not guaranteed and will typically fail with hard to understand > compilation errors during the build." > > I tried last year to build the tools "--with_ada" on Ubuntu, OpenSUSE, > Fedora, AlmaLinux and Debian. Moreover, I tried all versions of GNAT > each of the OS offered "normal" users to install. Only GNAT 10 worked > for me. Nothing else. > > The text in the chapter your cited can be understood this way: Compiling > ADA with a native compiler of the same version will work. If the native > compiler has a higher version it, is rather unlikely to work. If the > native compiler has a lower version, it may work or not. So, I do not > think you can file a bug with GCC. > When I more regularly built Ada, I always used the native Ada compiler to build the same version of GCC I was going to use with RTEMS natively with Ada enabled. I didn't care what version of GCC/Ada was from the OS. + OS GCC/Ada -> + native using RTEMS GCC version + cross compiler for RTEMS with Ada At least now you don't have to build RTEMS to have some headers and libraries before you build Ada. Long ago, you had to build a cross C/C++ compiler first to build RTEMS, then use the RTEMS libraries as part of building the toolchain with Ada. Also as I mentioned to Sebastian privately, Ada is likely to build for all targets except those where float and double are the same size. I only remember sh as having a multilib like this but I feel like there is another case. As for trivia, GNAT/RTEMS first passed the ACVC formally in March 1997 on the sparc/erc32. It's been around a long time. ;) --joel > Greetings > fk > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6? (Can Ada be used?)
On 4/27/22 20:12, Frank Kühndel wrote: Hi Karel, On 4/27/22 19:46, Karel Gardas wrote: On 4/27/22 19:25, Frank Kühndel wrote: I do not need ADA but ADA may be worth considering. With GCC 10 one needed to have a GNAT 10 compiler installed to build the tools incl. --with_ada. I presume, one would need a GNAT 12 to build ADA with the GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I know of have GNAT 10 at best (I have not checked on tumbleweed yet). OpenSUSE may get ADA 12 from an unusual repro??? On https://gcc.gnu.org/install/prerequisites.html there is a text: " GNAT In order to build GNAT, the Ada compiler, you need a working GNAT compiler (GCC version 5.1 or later). ... " is it outdated? If so, this would require some bugreport to gcc team? The text says too: "Other native compiler versions may work but this is not guaranteed and will typically fail with hard to understand compilation errors during the build." Hmm, I see, thanks for correcting me, but your citation is missing one important detail: "In order to build a cross compiler, it is strongly recommended to install the new compiler as native first, and then use it to build the cross compiler." So I'm afraid this looks like ball is on the RSB side which should first build native compiler of required version -- for this you may use older GNAT (at least GCC 5.1) and then use exactly this compiler to build a cross-compiler. E.g. GNAT 10 native -> GNAT 12 native -> GNAT 12 cross-compiler (RTEMS). Is that correct? Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6? (Can Ada be used?)
Hi Karel, On 4/27/22 19:46, Karel Gardas wrote: > On 4/27/22 19:25, Frank Kühndel wrote: >> I do not need ADA but ADA may be worth considering. With GCC 10 one >> needed to have a GNAT 10 compiler installed to build the tools incl. >> --with_ada. I presume, one would need a GNAT 12 to build ADA with the >> GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I >> know of have GNAT 10 at best (I have not checked on tumbleweed yet). >> OpenSUSE may get ADA 12 from an unusual repro??? > > On https://gcc.gnu.org/install/prerequisites.html there is a text: > > " > GNAT > > In order to build GNAT, the Ada compiler, you need a working GNAT > compiler (GCC version 5.1 or later). > > ... > " > > is it outdated? If so, this would require some bugreport to gcc team? The text says too: "Other native compiler versions may work but this is not guaranteed and will typically fail with hard to understand compilation errors during the build." I tried last year to build the tools "--with_ada" on Ubuntu, OpenSUSE, Fedora, AlmaLinux and Debian. Moreover, I tried all versions of GNAT each of the OS offered "normal" users to install. Only GNAT 10 worked for me. Nothing else. The text in the chapter your cited can be understood this way: Compiling ADA with a native compiler of the same version will work. If the native compiler has a higher version it, is rather unlikely to work. If the native compiler has a lower version, it may work or not. So, I do not think you can file a bug with GCC. Greetings fk ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6? (Can Ada be used?)
On 4/27/22 19:25, Frank Kühndel wrote: I do not need ADA but ADA may be worth considering. With GCC 10 one needed to have a GNAT 10 compiler installed to build the tools incl. --with_ada. I presume, one would need a GNAT 12 to build ADA with the GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I know of have GNAT 10 at best (I have not checked on tumbleweed yet). OpenSUSE may get ADA 12 from an unusual repro??? On https://gcc.gnu.org/install/prerequisites.html there is a text: " GNAT In order to build GNAT, the Ada compiler, you need a working GNAT compiler (GCC version 5.1 or later). ... " is it outdated? If so, this would require some bugreport to gcc team? Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6? (Can Ada be used?)
Hello Sebastian, On 4/27/22 11:54, Sebastian Huber wrote: >> we have to select a GCC version for the RTEMS 6 release. Currently, >> GCC 10 is used, however, with the release of GCC 10.4 this year it >> will reach its end of life. Other options are GCC 11 and 12. GCC 12 >> will be released in the next weeks. It has some nice features: >> >> * Initialization of stack variables: >> >> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init >> >> >> * Improved static analysis with -fanalyzer >> >> * Improved gcov support, with the ability to back port changes from >> GCC 13: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593536.html >> >> * Upstream maintenance for the next three years >> >> The draw back is that it is brand new. > > The Ada support is broken in GCC 12 for most targets: I do not need ADA but ADA may be worth considering. With GCC 10 one needed to have a GNAT 10 compiler installed to build the tools incl. --with_ada. I presume, one would need a GNAT 12 to build ADA with the GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I know of have GNAT 10 at best (I have not checked on tumbleweed yet). OpenSUSE may get ADA 12 from an unusual repro??? So, if I am not mistaken, switching to GCC 12 will have the effect that the "normal" RTEMS ADA user will for quite a while not be able to build ADA. I am not sure how important that would be. Greetings fk ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: AW: AW: AW: [PATCH 07/12] kern_tc.c: Remove verification of th_generation for pps functions
On 27.04.22 15:13, gabriel.moy...@dlr.de wrote: On 07/04/2022 15:16, Sebastian Huber wrote: On 07/04/2022 15:10, gabriel.moy...@dlr.de wrote: Which sequence of function calls and timings cases the problem? This should be definitely a test case. The generation is updated every time tc_windup() is called. So it is more or less a race condition when it happens. This is not a race condition. The sequence counter is supposed to ensure a consistent state. You can't simply remove this. Maybe the PPS support requires that we use two timehands even for the uniprocessor configuration. For this, we have to understand under which conditions and use cases the generation change is an issue. In kern_tc.c there is this comment, which is a result from a discussion on a FreeBSD mailing list: /* * In FreeBSD, the timehands count is a tuning option from two to 16. The * tuning option was added since it is inexpensive and some FreeBSD users asked * for it to play around. The default value is two. One system which did not * work with two timehands was a system with one processor and a specific PPS * device. * * For RTEMS, in uniprocessor configurations, just use one timehand since the * update is done with interrupt disabled. * * In SMP configurations, use a fixed set of two timehands until someone * reports an issue. */ We definitely need a test case for this corner case. Adding a second timehand has a size impact. On a 32-bit machine there is sizeof(struct timehands) == 120. What do you think about something in the middle between adding a second timehand and not adding it at all for non-SMP configurations? Let me explain better the idea; the pps_event() uses only 3 variables of the object timehand: th_offsetcount, th_bintime and th_scale. The values of them could be saved instruct pps_state during pps_capture(). This will only happen in case of non-SMP configurations. Then, the verifications need to be adapted for SMP or for non-SMP, e.g. the th_generation will be checked at the end of pps_capture() for both configurations but only for SMP in pps_event(). I would keep the synchronization as it is in FreeBSD for now and add a test case which fails in non-SMP configurations. This can be used to discuss the trade-offs. We need such a test case anyway. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6?
On 27.04.22 11:54, Sebastian Huber wrote: The Ada support is broken in GCC 12 for most targets: tracebak.c:563:2: error: #error Unhandled RTEMS architecture. 563 | #error Unhandled RTEMS architecture. | ^ Fortunately, this was easy to fix. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: AW: AW: AW: AW: [PATCH 11/12] kern_ntptime: Add define in order to remove warning
> On 08/04/2022 08:28, gabriel.moy...@dlr.de wrote: > PPS device drivers should use the kernel space API. Since we don't > have a user and kernel space in RTEMS, the kerne space API should be > available also if __rtems__ is defined. > >>> So, you mean to remove the #ifdef _KERNEL using #ifndef__rtems__. > >> It is an > >> > >> #ifdef _KERNEL > >> ... > >> #else /* !_KERNEL */ > >> ... > >> #endif /* KERNEL */ > >> > >> In RTEMS we need both APIs, one for PPS drivers and the other for > >> applications. > >> > >> If we don't want to change the header, then PPS drivers have to do > >> something like this: > >> > >> #define _KERNEL > >> #include > > Yes, that's why added the #define _KERNEL in kern_ntptime.c. > > What it is your suggestion here? > > We have currently no API which needs a _KERNEL define. Maybe we should > postpone the decision and keep the need for _KERNEL > define at this point in time. > Is it possible to comment them out with /* */? Because adding the #define _KERNEL and #include could generate some issues while compiling and this depends on the position where the header was included ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: AW: AW: [PATCH 07/12] kern_tc.c: Remove verification of th_generation for pps functions
> On 07/04/2022 15:16, Sebastian Huber wrote: > > On 07/04/2022 15:10, gabriel.moy...@dlr.de wrote: > >>> Which sequence of function calls and timings cases the problem? This > >>> should be definitely a test case. > >> The generation is updated every time tc_windup() is called. So it is > >> more or less a race condition when it happens. > > > > This is not a race condition. The sequence counter is supposed to > > ensure a consistent state. You can't simply remove this. > > > > Maybe the PPS support requires that we use two timehands even for the > > uniprocessor configuration. For this, we have to understand under > > which conditions and use cases the generation change is an issue. > > In kern_tc.c there is this comment, which is a result from a discussion on a > FreeBSD mailing list: > > /* > * In FreeBSD, the timehands count is a tuning option from two to 16. The > * tuning option was added since it is inexpensive and some FreeBSD users > asked > * for it to play around. The default value is two. One system which did > not > * work with two timehands was a system with one processor and a specific PPS > * device. > * > * For RTEMS, in uniprocessor configurations, just use one timehand since the > * update is done with interrupt disabled. > * > * In SMP configurations, use a fixed set of two timehands until someone > * reports an issue. > */ > > We definitely need a test case for this corner case. Adding a second timehand > has a size impact. On a 32-bit machine there is > sizeof(struct > timehands) == 120. > What do you think about something in the middle between adding a second timehand and not adding it at all for non-SMP configurations? Let me explain better the idea; the pps_event() uses only 3 variables of the object timehand: th_offsetcount, th_bintime and th_scale. The values of them could be saved instruct pps_state during pps_capture(). This will only happen in case of non-SMP configurations. Then, the verifications need to be adapted for SMP or for non-SMP, e.g. the th_generation will be checked at the end of pps_capture() for both configurations but only for SMP in pps_event(). ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6?
On 27.04.22 08:57, Sebastian Huber wrote: Hello, we have to select a GCC version for the RTEMS 6 release. Currently, GCC 10 is used, however, with the release of GCC 10.4 this year it will reach its end of life. Other options are GCC 11 and 12. GCC 12 will be released in the next weeks. It has some nice features: * Initialization of stack variables: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init * Improved static analysis with -fanalyzer * Improved gcov support, with the ability to back port changes from GCC 13: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593536.html * Upstream maintenance for the next three years The draw back is that it is brand new. The Ada support is broken in GCC 12 for most targets: tracebak.c:563:2: error: #error Unhandled RTEMS architecture. 563 | #error Unhandled RTEMS architecture. | ^ checking whether /home/EB/sebastian_h/src/rtems-source-builder/rtems/build/arm-rtems7-gcc-39d2411-newlib-64b2081-x86_64-linux-gnu-1/build/./gcc/xgcc -B/home/EB/sebastian_h/src/rtems-source-builder/rtems/build/arm-rtems7-gcc-39d2411-newlib-64b2081-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/home/EB/sebastian_h/src/rtems-source-builder/rte ms/build/arm-rtems7-gcc-39d2411-newlib-64b2081-x86_64-linux-gnu-1/build/arm-rtems7/thumb/cortex-m4+nofp/newlib/ -isystem /home/EB/sebastian_h/src/rtems-source-builder/rtems/build/arm-rtems7-gcc-39d2411-newlib-64b2081-x86_64-linux-gnu-1/build/arm-rtems7/thumb/cortex-m4+nofp/newlib/targ-include -isystem /home/EB/sebastian_h/src/rtems-source -builder/rtems/build/arm-rtems7-gcc-39d2411-newlib-64b2081-x86_64-linux-gnu-1/gnu-mirror-gcc-39d2411/newlib/libc/include -B/opt/rtems/7/arm-rtems7/bin/ -B/opt/rtems/7/arm-rtems7/lib/ -isystem /opt/rtems/7/arm-rtems7/include -isystem /opt/rtems/7/arm-rtems7/sys-include -mthumb -mcpu=cortex-m4+nofp understands -c and -o together... no tracebak.c: In function 'trace_callback': tracebak.c:660:12: error: '_URC_NORMAL_STOP' undeclared (first use in this function) 660 | return _URC_NORMAL_STOP; |^~~~ tracebak.c:660:12: note: each undeclared identifier is reported only once for each function it appears in tracebak.c:663:62: error: 'PC_ADJUST' undeclared (first use in this function) 663 | uw_data->traceback [uw_data->n_entries_filled ++] = pc + PC_ADJUST; | ^ -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
