Re: GCC version for RTEMS 6? (Can Ada be used?)
On 27.04.22 19:25, Frank Kühndel wrote: 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??? There is a GCC development repository for openSUSE which all current GCC versions: https://download.opensuse.org/repositories/devel:/gcc/ 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. I already fixed the Ada build. -- 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/4/2022 4:57 pm, 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. > What about rtems 6 shipping with 10 and then we move to 12 and test and if it looks good we release 7? The rational is my testing with rtems 6 + gcc 10 is good so we have a stable base to move from. Without this step we have no means for users to move back if there are issues. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[RTEMS 5] heap: Fix heap statistics with protection enabled
Close #4643.
---
cpukit/include/rtems/score/heapimpl.h | 10 +-
cpukit/score/src/heapallocate.c | 9 +
testsuites/libtests/malloctest/init.c | 4
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/cpukit/include/rtems/score/heapimpl.h
b/cpukit/include/rtems/score/heapimpl.h
index d3ee0ff88a..f74b5fc562 100644
--- a/cpukit/include/rtems/score/heapimpl.h
+++ b/cpukit/include/rtems/score/heapimpl.h
@@ -407,15 +407,7 @@ Heap_Block *_Heap_Block_allocate(
(*heap->Protection.block_error)( heap, block, reason );
}
- static inline void _Heap_Protection_free_all_delayed_blocks( Heap_Control
*heap )
- {
-uintptr_t large = 0
- - (uintptr_t) HEAP_BLOCK_HEADER_SIZE
- - (uintptr_t) HEAP_ALLOC_BONUS
- - (uintptr_t) 1;
-void *p = _Heap_Allocate( heap, large );
-_Heap_Free( heap, p );
- }
+ void _Heap_Protection_free_all_delayed_blocks( Heap_Control *heap );
#endif
/**
diff --git a/cpukit/score/src/heapallocate.c b/cpukit/score/src/heapallocate.c
index 4b8b3f0de6..1c71e4a037 100644
--- a/cpukit/score/src/heapallocate.c
+++ b/cpukit/score/src/heapallocate.c
@@ -73,6 +73,15 @@
return search_again;
}
+
+ void _Heap_Protection_free_all_delayed_blocks( Heap_Control *heap )
+ {
+bool search_again;
+
+do {
+ search_again = _Heap_Protection_free_delayed_blocks( heap, 0 );
+} while ( search_again );
+ }
#endif
#ifdef RTEMS_HEAP_DEBUG
diff --git a/testsuites/libtests/malloctest/init.c
b/testsuites/libtests/malloctest/init.c
index 1d91385683..1e5c14fe4b 100644
--- a/testsuites/libtests/malloctest/init.c
+++ b/testsuites/libtests/malloctest/init.c
@@ -122,9 +122,13 @@ static void test_heap_default_init(void)
static void test_free( void *addr )
{
+ uint32_t failed_allocs;
+
rtems_test_assert( _Heap_Free( &TestHeap, addr ) );
+ failed_allocs = TestHeap.stats.failed_allocs;
_Heap_Protection_free_all_delayed_blocks( &TestHeap );
+ rtems_test_assert( failed_allocs == TestHeap.stats.failed_allocs );
}
static void test_heap_cases_1(void)
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6?
On 28.04.22 09:52, Chris Johns wrote: On 27/4/2022 4:57 pm, 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. What about rtems 6 shipping with 10 and then we move to 12 and test and if it looks good we release 7? The rational is my testing with rtems 6 + gcc 10 is good so we have a stable base to move from. Without this step we have no means for users to move back if there are issues. More releases means more maintenance overhead. Since GCC 12 is under active upstream maintenance, compiler issues can be fixed by the GCC maintainers in contrast to GCC 10. -- 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?
Hello, I'd go with 12 if only a bit possible. Any major compiler change during the minor RTEMS release would not look good IMHO. It's way better to do major RTEMS version bump together with major compiler version bump and stick to that during the RTEMS release live cycle. That's my gut feeling about that. Now, hard evidence. Do we have any table comparing test case results on all the (tier 1? /2?) platforms between GCC 10 and 12? That would be great to have that to see if there is any major regression in 12 and to possibly drive the decision based on hard facts. Thanks! Karel On 4/27/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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS 6 toolchain on a Mac
Hallo Sebastian, maybe too late, but this is the result of RTEMS 7 rsb on my Mac: Command Line: ../source-builder/sb-set-builder --jobs=4 --prefix=/Users/heinz/VE/ARM_WORK/rtems/7 7/rtems-arm Python: 3.8.5 (default, Sep 4 2020, 02:22:02) [Clang 10.0.0 ] https://github.com/RTEMS/rtems-source-builder.git/origin/a53d2c94322ed4fe261ba0c99bfb66a6cbd1def1 ... CXXunittests/tui-selftests.o In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/unittests/string_view-selftests.c:34: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/fstream:579:17: warning: The symbol ::fdopen refers to the system function. Use gnulib::fdopen instead. [-Wuser-defined-warnings] __file_ = fdopen(__fd, __mdstr); ^ ../gnulib/import/stdio.h:826:1: note: from 'diagnose_if' attribute on 'fdopen': _GL_CXXALIASWARN (fdopen); ^ ../gnulib/import/stdio.h:461:4: note: expanded from macro '_GL_CXXALIASWARN' _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE) ^~~ ../gnulib/import/stdio.h:463:4: note: expanded from macro '_GL_CXXALIASWARN_1' _GL_CXXALIASWARN_2 (func, namespace) ^~~~ ../gnulib/import/stdio.h:468:5: note: expanded from macro '_GL_CXXALIASWARN_2' _GL_WARN_ON_USE (func, \ ^~~~ ../gnulib/import/stdio.h:632:19: note: expanded from macro '_GL_WARN_ON_USE' __attribute__ ((__diagnose_if__ (1, message, "warning"))) ^~ CXXunittests/ui-file-selftests.o CXXunittests/unique_xmalloc_ptr_char.o CXXunittests/unpack-selftests.o 1 warning generated. CXXunittests/utils-selftests.o CXXunittests/vec-utils-selftests.o CXXunittests/xml-utils-selftests.o CXXuser-regs.o CXXutils.o CXXvalarith.o CXXvalops.o CXXvalprint.o CXXvalue.o CXXvarobj.o GENstamp-version GENxml-builtin.c CXXxml-support.o CXXxml-syscall.o CXXxml-tdesc.o GENinit.c CXXgdb.o CXXaarch32-tdep.o CXXada-exp.o CXXada-lang.o CXXada-tasks.o CXXada-typeprint.o CXXada-valprint.o CXXada-varobj.o CXXaddrmap.o CXXagent.o CXXalloc.o CXXannotate.o CXXarch-utils.o CXXarch/aarch32.o CXXarch/arm-get-next-pcs.o CXXarch/arm.o CXXarm-none-tdep.o CXXarm-pikeos-tdep.o CXXarm-tdep.o CXXasync-event.o CXXauto-load.o CXXauxv.o CXXax-gdb.o CXXax-general.o CXXbcache.o CXXbfd-target.o CXXblock.o CXXblockframe.o CXXbreak-catch-exec.o CXXbreak-catch-fork.o CXXbreak-catch-sig.o CXXbreak-catch-syscall.o CXXbreak-catch-throw.o CXXbreakpoint.o CXXbt-utils.o CXXbtrace.o CXXbuild-id.o CXXbuildsym-legacy.o CXXbuildsym.o CXXc-exp.o CXXc-lang.o CXXc-typeprint.o CXXc-valprint.o CXXc-varobj.o CXXcharset.o CXXcli-out.o CXXcli/cli-cmds.o CXXcli/cli-decode.o CXXcli/cli-dump.o CXXcli/cli-interp.o CXXcli/cli-logging.o CXXcli/cli-option.o CXXcli/cli-script.o CXXcli/cli-setshow.o CXXcli/cli-style.o CXXcli/cli-utils.o CXXcoff-pe-read.o CXXcoffread.o CXXcompile/compile-c-support.o CXXcompile/compile-c-symbols.o CXXcompile/compile-c-types.o CXXcompile/compile-cplus-symbols.o CXXcompile/compile-cplus-types.o CXXcompile/compile-loc2c.o CXXcompile/compile-object-load.o CXXcompile/compile-object-run.o CXXcompile/compile.o CXXcomplaints.o CXXcompleter.o CXXcopying.o CXXcorefile.o CXXcorelow.o CXXcp-abi.o CXXcp-name-parser.o CXXcp-namespace.o CXXcp-support.o CXXcp-valprint.o CXXctfread.o CXXd-exp.o CXXf-exp.o CXXm2-exp.o CXXgo-exp.o In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/m2-exp.y:42: In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/language.h:26: In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/symtab.h:39: ../../sourceware-mirror-binutils-gdb-36b1241/gdb/split-name.h:34:3: error: expected identifier DOT, ^ m2-exp.c:163:13: note: expanded from macro 'DOT' #define DOT 302 ^ In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/m2-exp.y:42: In file included from ../../sourceware-mirror-binutils-gdb-36b1241/gdb/language.h:26: ../../sourceware-mirror-binutils-gdb-36b1241/gdb/symtab.h:306:23: error: expected unqualified-id style = split_style::DOT; ^ m2-exp.c:163:13: note: expanded from macro 'DOT' #define DOT 302 ^ 2 errors generated. make[2]: *** [m2-exp.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]
Re: GCC version for RTEMS 6? (Can Ada be used?)
Hello, On 4/27/22 20:22, Joel Sherrill wrote: > 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 With "native using RTEMS GCC version" you mean you downloaded the official GCC tar-ball and build an Ada compiler following the README/Install instructions? I was always thinking that building an Ada non-cross compiler would run into the same errors as building an Ada cross compiler. Interesting. I have no time to test it right now but I will write it on my list and give it a try. In case that will work, Karel would be right. The RSB should at least check the GNAT Version and issue a warning or error instead of letting users marvel around why the Ada cross compiler failed to build with a bizarre error. > > 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. I tried on all targets and Ada does not build on sh and lm32 (tested on Ubuntu, Debian, OpenSUSE with RTEMS 6 and GNAT 10). Greetings fk Ada on Sh failure (Debian 11) ../gcc-interface/Makefile:299: update target 's-soflin.o' due to: s-soflin.adb /home/minna/src/rtems-source-builder/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64 b2081-x86_64-linux-gnu-1/build/./gcc/xgcc -B/home/minna/src/rtems-source-builder /rtems/build/sh-rtems6-gcc-0f001dd-newlib-64b2081-x86_64-linux-gnu-1/build/./gcc / -nostdinc -B/home/minna/src/rtems-source-builder/rtems/build/sh-rtems6-gcc-0f0 01dd-newlib-64b2081-x86_64-linux-gnu-1/build/sh-rtems6/newlib/ -isystem /home/mi nna/src/rtems-source-builder/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64b2081-x8 6_64-linux-gnu-1/build/sh-rtems6/newlib/targ-include -isystem /home/minna/src/rt ems-source-builder/rtems/build/sh-rtems6-gcc-0f001dd-newlib-64b2081-x86_64-linux -gnu-1/gnu-mirror-gcc-0f001dd/newlib/libc/include -B/opt/rtems/6/sh-rtems6/bin/ -B/opt/rtems/6/sh-rtems6/lib/ -isystem /opt/rtems/6/sh-rtems6/include -isystem / opt/rtems/6/sh-rtems6/sys-include-c -g -O2 -m4-single-only -W -Wall -gnatpg -nostdinc -m4-single-only s-soflin.adb -o s-soflin.o s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object s-scaval.adb:103:07: warning: program execution may be erroneous s-scaval.adb:103:07: warning: size of "IV_Ilf" is 64 s-scaval.adb:103:07: warning: size of "IS_Ilf" is 32 s-scaval.adb:104:07: warning: "IV_Ill" overlays smaller object s-scaval.adb:104:07: warning: program execution may be erroneous s-scaval.adb:104:07: warning: size of "IV_Ill" is 96 s-scaval.adb:104:07: warning: size of "IS_Ill" is 64 make[8]: *** [../gcc-interface/Makefile:299: s-scaval.o] Error 1 Ada failure on lm32 (Ubuntu 22.04) ../gcc-interface/Makefile:302: update targ
Feature list only in user guide
Hello, I was looking for a list of RTEMS Features (e.g. supported language, drives, BSPs, etc.) I expected it on www.rtems.org and did not find anything till a college of mine pointed me to the excellent list in the RTEMS User Manual: https://docs.rtems.org/branches/master/user/overview/index.html#features I would expect that a potential interested new RTEMS user would search such a list on the project home-page or maybe in the wiki. From a marketing point of view, would it not make sense to place this list or a link to it prominently on the home page? Just a thought fk -- embedded brains GmbH Herr Frank KÜHNDEL Dornierstr. 4 82178 Puchheim Germany email: frank.kuehn...@embedded-brains.de phone: +49-89-18 94 741 - 23 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: Feature list only in user guide
On Thu, Apr 28, 2022 at 8:53 AM Frank Kühndel < frank.kuehn...@embedded-brains.de> wrote: > Hello, > > I was looking for a list of RTEMS Features (e.g. supported language, > drives, BSPs, etc.) I expected it on www.rtems.org and did not find > anything till a college of mine pointed me to the excellent list in the > RTEMS User Manual: > > https://docs.rtems.org/branches/master/user/overview/index.html#features > > I would expect that a potential interested new RTEMS user would search > such a list on the project home-page or maybe in the wiki. From a > marketing point of view, would it not make sense to place this list or a > link to it prominently on the home page? > It should be checked to be sure it is up to date and definitely covered somewhere prominent. It looks like the page we long time folks likely think is very prominent and accessible isn't anymore. Before Trac, the top entry page of the Wiki was this type of overview with features. I think I found the page here in the TBR section of the Wiki. https://devel.rtems.org/wiki/TBR/Website/What_is_RTEMS This page (and maybe some others) likely need a refresh/rework and linked from the top of devel.rtems.org. If you just want info and are not trying to file a bug, that entry page is just not helping. I'm also curious how you think it compares to the list of things used in the first RTEMS manuals (early 90s). This is the proceedings with the first published paper on RTEMS (Aug 1990) and a lot of what is in the manuals as background first appeared in this paper. I expect you will recognize early versions of figures and love the font. It looks old. See page 247 in the PDF. https://web.archive.org/web/20170218223058/http://www.dtic.mil/dtic/tr/fulltext/u2/a247043.pdf I need to trim it and upload it to rtems.org. --joel > > Just a thought > fk > > -- > embedded brains GmbH > Herr Frank KÜHNDEL > Dornierstr. 4 > 82178 Puchheim > Germany > email: frank.kuehn...@embedded-brains.de > phone: +49-89-18 94 741 - 23 > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC version for RTEMS 6?
On 28/4/2022 6:04 pm, Sebastian Huber wrote: > On 28.04.22 09:52, Chris Johns wrote: >> On 27/4/2022 4:57 pm, 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. >>> >> What about rtems 6 shipping with 10 and then we move to 12 and test and if it >> looks good we release 7? >> >> The rational is my testing with rtems 6 + gcc 10 is good so we have a stable >> base to move from. Without this step we have no means for users to move back >> if >> there are issues. > > More releases means more maintenance overhead. Since GCC 12 is under active > upstream maintenance, compiler issues can be fixed by the GCC maintainers in > contrast to GCC 10. Yes it does mean that could happen but it also means 6 and 7 are closer in terms of rtems.git etc so back ports here are simpler. Plus if rtems 6 is not working and 7 is the user can just move forward to 7. I suppose there is no prefect solution and we do not have a crystal ball so we will have to decide and hope we are OK. The positive aspect is 6 and 7 will both be waf based and that helps deployment solutions user have, eg EPICS. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
AW: 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. > Unfortunately I could not reproduce the error again. Not sure what has changed that now it is not possible to reproduce it. So, I'll prepare new patches (without this trade-off solution) and send them again in order to get new feedback ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
