Odd warnings from spstdc17 from isrlock.h and scheduler.h
Hi
Noticed these building RTEMS for powerpc/psim today. SMP is disabled
In file included from ../../../cpukit/include/rtems/rtems/intr.h:73,
from ../../../cpukit/include/rtems.h:69,
from ../../../testsuites/sptests/spstdc17/init.c:32:
../../../cpukit/include/rtems/score/isrlock.h:72:9: warning: struct has no
members [-Wpedantic]
72 | typedef struct {
| ^~
In file included from ../../../cpukit/include/rtems/scheduler.h:40,
from ../../../cpukit/include/rtems/confdefs/scheduler.h:65,
from ../../../cpukit/include/rtems/confdefs/threads.h:49,
from ../../../cpukit/include/rtems/confdefs/inittask.h:56,
from ../../../cpukit/include/rtems/confdefs.h:68,
from ../../../testsuites/sptests/spstdc17/init.c:57:
../../../cpukit/include/rtems/score/scheduler.h:318:16: warning: struct has
no members [-Wpedantic]
318 | typedef struct Scheduler_Context {
|^
Hopefully someone sees the fix quickly.
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libdebugger: Restrict ARM architecture support
Hello On 04.08.23 07:07, Sebastian Huber wrote: On 04.08.23 00:43, Chris Johns wrote: On 3/8/2023 10:17 pm, Sebastian Huber wrote: Build the arm libdebugger support only for supported ARM architectures. What ARM archs are not supported? At least ARMv7-M and everything with Thumb 1. Is the the stm32h7 family (cortex-m7) supported? It's Thumb 2 and Armv7E-M If not, what is missing? Cedric ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] psxkey07: Fix POSIX key value pair configuration
This looks ok to commit.
On Fri, Aug 4, 2023 at 2:59 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Make sure we have enough POSIX key value pairs available. This fixes a
> test
> failure on some targets.
>
> Make objects and functions static. Initialize variable to get rid of
> warnings.
> ---
> testsuites/psxtests/psxkey07/init.c | 42 ++---
> 1 file changed, 20 insertions(+), 22 deletions(-)
>
> diff --git a/testsuites/psxtests/psxkey07/init.c
> b/testsuites/psxtests/psxkey07/init.c
> index 15387264ba..ff7b3a0bd0 100644
> --- a/testsuites/psxtests/psxkey07/init.c
> +++ b/testsuites/psxtests/psxkey07/init.c
> @@ -39,32 +39,27 @@
>
> const char rtems_test_name[] = "PSXKEY 7";
>
> -/* forward declarations to avoid warnings */
> -rtems_task Init(rtems_task_argument argument);
> -rtems_task Test_Thread(rtems_task_argument argument);
> +#define INITIAL_TASK_COUNT 10
>
> -pthread_key_t Key;
> -int created_thread_count, setted_thread_count, got_thread_count;
> -int all_thread_created;
> -pthread_mutex_t mutex1, mutex2;
> -pthread_cond_t create_condition_var, set_condition_var;
> +#define ADDITIONAL_TASK_COUNT 13
>
> -rtems_task Test_Thread(rtems_task_argument argument)
> +static pthread_key_t Key;
> +static int created_thread_count, setted_thread_count, got_thread_count;
> +static int all_thread_created;
> +static pthread_mutex_t mutex1, mutex2;
> +static pthread_cond_t create_condition_var, set_condition_var;
> +
> +static rtems_task Test_Thread(rtems_task_argument argument)
> {
>int sc;
>int *value_p, *value_p2;
>
>value_p = malloc( sizeof( int ) );
>rtems_test_assert(value_p != NULL);
> -/*
> - * This was added to address the following warning.
> - * warning: 'value_p' may be used uninitialized
> - */
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> - sc = pthread_setspecific( Key, value_p );
> -#pragma GCC diagnostic pop
> - rtems_test_assert( !sc );
> +
> + *value_p = 123;
> + sc = pthread_setspecific( Key, value_p );
> + rtems_test_assert( !sc );
>
>pthread_mutex_lock( );
>++setted_thread_count;
> @@ -86,12 +81,13 @@ rtems_task Test_Thread(rtems_task_argument argument)
>rtems_task_exit();
> }
>
> -rtems_task Init(rtems_task_argument argument)
> +static rtems_task Init(rtems_task_argument argument)
> {
>rtems_status_code rc;
>intsc;
>struct timespecdelay_request;
> - uintptr_t max_free_size = 13 * RTEMS_MINIMUM_STACK_SIZE;
> + uintptr_t max_free_size =
> + ADDITIONAL_TASK_COUNT * RTEMS_MINIMUM_STACK_SIZE;
>void *greedy;
>
>all_thread_created = 0;
> @@ -222,8 +218,10 @@ rtems_task Init(rtems_task_argument argument)
>
> #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
>
> -#define CONFIGURE_MAXIMUM_TASKS rtems_resource_unlimited(10)
> -#define CONFIGURE_MAXIMUM_POSIX_KEYS 1
> +#define CONFIGURE_MAXIMUM_TASKS
> rtems_resource_unlimited(INITIAL_TASK_COUNT)
> +#define CONFIGURE_MAXIMUM_POSIX_KEYS 1
> +#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS \
> + (INITIAL_TASK_COUNT + ADDITIONAL_TASK_COUNT)
> #define CONFIGURE_UNIFIED_WORK_AREAS
>
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> --
> 2.35.3
>
> ___
> 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: [PATCH] psxkey07: Fix POSIX key value pair configuration
On Fri, Aug 4, 2023 at 2:59 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Make sure we have enough POSIX key value pairs available. This fixes a
> test
> failure on some targets.
>
> Make objects and functions static. Initialize variable to get rid of
> warnings.
> ---
> testsuites/psxtests/psxkey07/init.c | 42 ++---
> 1 file changed, 20 insertions(+), 22 deletions(-)
>
> diff --git a/testsuites/psxtests/psxkey07/init.c
> b/testsuites/psxtests/psxkey07/init.c
> index 15387264ba..ff7b3a0bd0 100644
> --- a/testsuites/psxtests/psxkey07/init.c
> +++ b/testsuites/psxtests/psxkey07/init.c
> @@ -39,32 +39,27 @@
>
> const char rtems_test_name[] = "PSXKEY 7";
>
> -/* forward declarations to avoid warnings */
> -rtems_task Init(rtems_task_argument argument);
> -rtems_task Test_Thread(rtems_task_argument argument);
> +#define INITIAL_TASK_COUNT 10
>
> -pthread_key_t Key;
> -int created_thread_count, setted_thread_count, got_thread_count;
> -int all_thread_created;
> -pthread_mutex_t mutex1, mutex2;
> -pthread_cond_t create_condition_var, set_condition_var;
> +#define ADDITIONAL_TASK_COUNT 13
>
> -rtems_task Test_Thread(rtems_task_argument argument)
> +static pthread_key_t Key;
> +static int created_thread_count, setted_thread_count, got_thread_count;
> +static int all_thread_created;
> +static pthread_mutex_t mutex1, mutex2;
> +static pthread_cond_t create_condition_var, set_condition_var;
> +
> +static rtems_task Test_Thread(rtems_task_argument argument)
> {
>int sc;
>int *value_p, *value_p2;
>
>value_p = malloc( sizeof( int ) );
>rtems_test_assert(value_p != NULL);
> -/*
> - * This was added to address the following warning.
> - * warning: 'value_p' may be used uninitialized
> - */
> -#pragma GCC diagnostic push
> -#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
> - sc = pthread_setspecific( Key, value_p );
> -#pragma GCC diagnostic pop
> - rtems_test_assert( !sc );
> +
> + *value_p = 123;
> + sc = pthread_setspecific( Key, value_p );
> + rtems_test_assert( !sc );
>
>pthread_mutex_lock( );
>++setted_thread_count;
> @@ -86,12 +81,13 @@ rtems_task Test_Thread(rtems_task_argument argument)
>rtems_task_exit();
> }
>
> -rtems_task Init(rtems_task_argument argument)
> +static rtems_task Init(rtems_task_argument argument)
> {
>rtems_status_code rc;
>intsc;
>struct timespecdelay_request;
> - uintptr_t max_free_size = 13 * RTEMS_MINIMUM_STACK_SIZE;
> + uintptr_t max_free_size =
> + ADDITIONAL_TASK_COUNT * RTEMS_MINIMUM_STACK_SIZE;
>void *greedy;
>
>all_thread_created = 0;
> @@ -222,8 +218,10 @@ rtems_task Init(rtems_task_argument argument)
>
> #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
>
> -#define CONFIGURE_MAXIMUM_TASKS rtems_resource_unlimited(10)
> -#define CONFIGURE_MAXIMUM_POSIX_KEYS 1
> +#define CONFIGURE_MAXIMUM_TASKS
> rtems_resource_unlimited(INITIAL_TASK_COUNT)
> +#define CONFIGURE_MAXIMUM_POSIX_KEYS 1
> +#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS \
> + (INITIAL_TASK_COUNT + ADDITIONAL_TASK_COUNT)
> #define CONFIGURE_UNIFIED_WORK_AREAS
>
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> --
> 2.35.3
>
> ___
> 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: [PATCH 3/3] Force ISR enable before scheduler start
On 04.08.23 12:15, EYSSARTIER Kevin wrote: I agree that my solution is not good but moving _RISCV_Start_multitasking out of the ‘#ifdef RTEMS_SMP’ barrier seems to bring many side effects. You have to provide this function for all configurations, however, with different implementations. -- 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: [PATCH 3/3] Force ISR enable before scheduler start
Classified as: {OPEN}
I don't know how to run the tests.
I observe that _Thread_Do_dispatch fails with
INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT because
RTEMS_SCORE_ROBUST_THREAD_DISPATCH is activated and the _ISR_Is_enabled returns
false.
Indeed, the _CPU_Start_multitasking should be called properly, but the
_RISCV_Start_multitasking function is only present when the RTEMS_SMP flag is
activated. There is something that seems strange between the multitask and SMP
functionalities in the riscv-context-switch.S file. A single core system should
be capable of running a multitask system.
I agree that my solution is not good but moving _RISCV_Start_multitasking out
of the '#ifdef RTEMS_SMP' barrier seems to bring many side effects.
Best regards,
---
Kevin EYSSARTIER, Research Engineer
Thales Research & Technology France - High Performance Computing Lab
Campus Polytechnique - 1, avenue Augustin Fresnel - 91767 Palaiseau cedex
Phone : +33 (0)1 69 41 55 14 Internal : 341 55 14
{OPEN}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] psxkey07: Fix POSIX key value pair configuration
Make sure we have enough POSIX key value pairs available. This fixes a test
failure on some targets.
Make objects and functions static. Initialize variable to get rid of warnings.
---
testsuites/psxtests/psxkey07/init.c | 42 ++---
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/testsuites/psxtests/psxkey07/init.c
b/testsuites/psxtests/psxkey07/init.c
index 15387264ba..ff7b3a0bd0 100644
--- a/testsuites/psxtests/psxkey07/init.c
+++ b/testsuites/psxtests/psxkey07/init.c
@@ -39,32 +39,27 @@
const char rtems_test_name[] = "PSXKEY 7";
-/* forward declarations to avoid warnings */
-rtems_task Init(rtems_task_argument argument);
-rtems_task Test_Thread(rtems_task_argument argument);
+#define INITIAL_TASK_COUNT 10
-pthread_key_t Key;
-int created_thread_count, setted_thread_count, got_thread_count;
-int all_thread_created;
-pthread_mutex_t mutex1, mutex2;
-pthread_cond_t create_condition_var, set_condition_var;
+#define ADDITIONAL_TASK_COUNT 13
-rtems_task Test_Thread(rtems_task_argument argument)
+static pthread_key_t Key;
+static int created_thread_count, setted_thread_count, got_thread_count;
+static int all_thread_created;
+static pthread_mutex_t mutex1, mutex2;
+static pthread_cond_t create_condition_var, set_condition_var;
+
+static rtems_task Test_Thread(rtems_task_argument argument)
{
int sc;
int *value_p, *value_p2;
value_p = malloc( sizeof( int ) );
rtems_test_assert(value_p != NULL);
-/*
- * This was added to address the following warning.
- * warning: 'value_p' may be used uninitialized
- */
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
- sc = pthread_setspecific( Key, value_p );
-#pragma GCC diagnostic pop
- rtems_test_assert( !sc );
+
+ *value_p = 123;
+ sc = pthread_setspecific( Key, value_p );
+ rtems_test_assert( !sc );
pthread_mutex_lock( );
++setted_thread_count;
@@ -86,12 +81,13 @@ rtems_task Test_Thread(rtems_task_argument argument)
rtems_task_exit();
}
-rtems_task Init(rtems_task_argument argument)
+static rtems_task Init(rtems_task_argument argument)
{
rtems_status_code rc;
intsc;
struct timespecdelay_request;
- uintptr_t max_free_size = 13 * RTEMS_MINIMUM_STACK_SIZE;
+ uintptr_t max_free_size =
+ ADDITIONAL_TASK_COUNT * RTEMS_MINIMUM_STACK_SIZE;
void *greedy;
all_thread_created = 0;
@@ -222,8 +218,10 @@ rtems_task Init(rtems_task_argument argument)
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
-#define CONFIGURE_MAXIMUM_TASKS rtems_resource_unlimited(10)
-#define CONFIGURE_MAXIMUM_POSIX_KEYS 1
+#define CONFIGURE_MAXIMUM_TASKS rtems_resource_unlimited(INITIAL_TASK_COUNT)
+#define CONFIGURE_MAXIMUM_POSIX_KEYS 1
+#define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS \
+ (INITIAL_TASK_COUNT + ADDITIONAL_TASK_COUNT)
#define CONFIGURE_UNIFIED_WORK_AREAS
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] trace/wscript: Improve C++ standard selection
On 04.08.23 08:30, Chris Johns wrote: Please understand there is a limited number people reviewing and it takes time. I am blocked on the other changes you have recently posted. Adding which hosts you have built and tested this change on would help? Sorry, Joel is rushing for the RTEMS 6 release. The patch is from 19.05.23. A CI system and pull requests would also help. Ah yes and I have raised an 7 related RSB sources fetch that need to be fix as well. My concern is release testing on hosts like MacOS M etc tend to find issues if it has not been tested. GitHub offers runners for macOS: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners I don't understand why we don't use the GitHub services for the project. It is just a matter of adding a couple for text files to the repositories. You can still run your own GitLab stuff in parallel. It is not one or another. You can have both. -- 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: [PATCH] build: Add PROGRAM_PREFIX option
On 04.08.23 08:22, Chris Johns wrote: On 4/8/2023 3:16 pm, Sebastian Huber wrote: On 04.08.23 00:27, Chris Johns wrote: On 2/8/2023 6:49 pm, Chris Johns wrote: > I am concerned about the compatibility to the ecosystem we have. Have you built all the tests in the testsuite with this value set to something that is not RTEMS default? I think a few things will break because of hard coding in them. I have asked for test results and I have not seen any yet the patch has been merged? The change was not approved my me and is still not approved. Sorry I thought it was fine after answering your questions. All good, I would like to finish the discusion. :) Yes, I have tested this with the rtems7 tools. It was possible to build with the rtems7 tools before, however, the PROGRAM_PREFIX approach is better, since it allows also the build using vendor tools. We had some fixes for this recently: https://lists.rtems.org/pipermail/devel/2023-May/075321.html This is something the user need. What if a user adds or uses a prefix that does not conform to the standard format? I am assuming this is possible to do this, eg Gaisler's special prefix? Possible breakage is https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457 ? Do we need to document any constraints around this option? There will be always problems left to fix. A basic build and the normal tests work fine with non-standard tools. For the Gaisler tools, you would need: PROGRAM_PREFIX = sparc-gaisler-rtems5- I guess the rld-cc.cpp will also have issues with a clang build. I have problems to send test reports by e-mail: Anything Amar or I can help with? Chris -- 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: [PATCH] trace/wscript: Improve C++ standard selection
On 4/8/2023 3:02 pm, Sebastian Huber wrote: > On 04.08.23 00:53, Chris Johns wrote: >> On 3/8/2023 5:36 pm, Sebastian Huber wrote: >>> Ping. >> >> Which repo? Is this in the rtems-tools repo? > > Yes, the rtems-tools. > Thanks > Please understand there is a limited number people reviewing and it takes > time. >> I am blocked on the other changes you have recently posted. Adding which >> hosts >> you have built and tested this change on would help? > > Sorry, Joel is rushing for the RTEMS 6 release. The patch is from 19.05.23. A > CI > system and pull requests would also help. Ah yes and I have raised an 7 related RSB sources fetch that need to be fix as well. My concern is release testing on hosts like MacOS M etc tend to find issues if it has not been tested. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] libdebugger: Restrict ARM architecture support
On 4/8/2023 3:07 pm, Sebastian Huber wrote: > On 04.08.23 00:43, Chris Johns wrote: >> On 3/8/2023 10:17 pm, Sebastian Huber wrote: >>> Build the arm libdebugger support only for supported ARM architectures. >> What ARM archs are not supported? > > At least ARMv7-M and everything with Thumb 1. > Does the rtems_debugger_target_configure fail in this patch for this arch? >>> This fixes assembler errors at -O0. >> How does it fix the assembler errors? > > The unsupported assembly instructions are not issued by the compiler so that > the > assembler is happy. This issue is open since 2020: > > https://lists.rtems.org/pipermail/devel/2020-March/058432.html Yes. > > Since the gcov code coverage is generated using -O0, this is now a bigger > issue. > Why is RPi showing issues? That is confusing me. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] build: Add PROGRAM_PREFIX option
On 4/8/2023 3:16 pm, Sebastian Huber wrote: > On 04.08.23 00:27, Chris Johns wrote: >> On 2/8/2023 6:49 pm, Chris Johns wrote: >> > I am concerned about the compatibility to the ecosystem we have. Have you >> built >>> all the tests in the testsuite with this value set to something that is not >>> RTEMS default? I think a few things will break because of hard coding in >>> them. >> I have asked for test results and I have not seen any yet the patch has been >> merged? The change was not approved my me and is still not approved. > > Sorry I thought it was fine after answering your questions. All good, I would like to finish the discusion. :) > Yes, I have tested this with the rtems7 tools. It was possible to build with > the rtems7 tools > before, however, the PROGRAM_PREFIX approach is better, since it allows also > the > build using vendor tools. We had some fixes for this recently: > > https://lists.rtems.org/pipermail/devel/2023-May/075321.html > > This is something the user need. What if a user adds or uses a prefix that does not conform to the standard format? I am assuming this is possible to do this, eg Gaisler's special prefix? Possible breakage is https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n457 ? Do we need to document any constraints around this option? > I have problems to send test reports by e-mail: Anything Amar or I can help with? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
