[PATCH] Remove obsolete rtems_gxx_*() implementation

2022-01-26 Thread Sebastian Huber
GCC versions prior to 6.1 used a RTEMS thread model based on
rtems_gxx_*() functions. GCC version 6.1 or later uses the
self-contained synchronization objects of Newlib  for the
RTEMS thread model.

Remove the obsolete implementation.

Close #3143.
---
 cpukit/include/rtems/gxx_wrappers.h |  80 --
 cpukit/include/rtems/score/interr.h |   4 +-
 cpukit/libcsupport/src/gxx_wrappers.c   | 261 
 spec/build/testsuites/libtests/grp.yml  |   2 -
 spec/build/testsuites/libtests/gxx01.yml|  19 --
 spec/build/testsuites/sptests/grp.yml   |   4 -
 spec/build/testsuites/sptests/spfatal24.yml |  19 --
 spec/build/testsuites/sptests/spfatal25.yml |  19 --
 testsuites/libtests/gxx01/gxx01.doc |  33 ---
 testsuites/libtests/gxx01/gxx01.scn |  35 ---
 testsuites/libtests/gxx01/init.c| 228 -
 testsuites/sptests/spfatal24/init.c |  31 ---
 testsuites/sptests/spfatal24/spfatal24.doc  |  19 --
 testsuites/sptests/spfatal24/spfatal24.scn  |   3 -
 testsuites/sptests/spfatal25/init.c |  33 ---
 testsuites/sptests/spfatal25/spfatal25.doc  |  19 --
 testsuites/sptests/spfatal25/spfatal25.scn  |   3 -
 17 files changed, 2 insertions(+), 810 deletions(-)
 delete mode 100644 cpukit/include/rtems/gxx_wrappers.h
 delete mode 100644 cpukit/libcsupport/src/gxx_wrappers.c
 delete mode 100644 spec/build/testsuites/libtests/gxx01.yml
 delete mode 100644 spec/build/testsuites/sptests/spfatal24.yml
 delete mode 100644 spec/build/testsuites/sptests/spfatal25.yml
 delete mode 100644 testsuites/libtests/gxx01/gxx01.doc
 delete mode 100644 testsuites/libtests/gxx01/gxx01.scn
 delete mode 100644 testsuites/libtests/gxx01/init.c
 delete mode 100644 testsuites/sptests/spfatal24/init.c
 delete mode 100644 testsuites/sptests/spfatal24/spfatal24.doc
 delete mode 100644 testsuites/sptests/spfatal24/spfatal24.scn
 delete mode 100644 testsuites/sptests/spfatal25/init.c
 delete mode 100644 testsuites/sptests/spfatal25/spfatal25.doc
 delete mode 100644 testsuites/sptests/spfatal25/spfatal25.scn

diff --git a/cpukit/include/rtems/gxx_wrappers.h 
b/cpukit/include/rtems/gxx_wrappers.h
deleted file mode 100644
index e462d27d66..00
--- a/cpukit/include/rtems/gxx_wrappers.h
+++ /dev/null
@@ -1,80 +0,0 @@
-/**
- * @file
- *
- * RTEMS threads compatibility routines for libgcc2.
- */
-
-/*
- *  by: Rosimildo da Silva (rdasi...@connecttel.com)
- *
- *  Used ideas from:
- *W. Eric Norum
- *Canadian Light Source
- *University of Saskatchewan
- *Saskatoon, Saskatchewan, CANADA
- *e...@cls.usask.ca
- *
- *  Eric sent some e-mail in the rtems-list as a start point for this
- *  module implementation.
- */
-
-#ifndef __GCC_WRAPPERS_h 
-#define __GCC_WRAPPERS_h
-
-#ifdef __cplusplus
-extern "C" {
-#endif /* __cplusplus */
-
-/**
- *  @defgroup GxxWrappersSupport Gxx Wrappers Support
- *
- *  @ingroup libcsupport
- *
- *  @brief RTEMS Threads Compatibility Routines for Libgcc2
- */
-
-/*
- * These typedefs should match with the ones defined in the file
- * gcc/gthr-rtems.h in the gcc distribution.
- */
-typedef void *__gthread_key_t;
-typedef int   __gthread_once_t;
-typedef void *__gthread_mutex_t;
-typedef void *__gthread_recursive_mutex_t;
-
-int rtems_gxx_once(__gthread_once_t *once, void (*func) (void));
-
-int rtems_gxx_key_create (__gthread_key_t *key, void (*dtor) (void *));
-
-int rtems_gxx_key_delete (__gthread_key_t key);
-
-void *rtems_gxx_getspecific(__gthread_key_t key);
-
-int rtems_gxx_setspecific(__gthread_key_t key, const void *ptr);
-
-/*
- * MUTEX support
- */
-void rtems_gxx_mutex_init (__gthread_mutex_t *mutex);
-
-int rtems_gxx_mutex_lock (__gthread_mutex_t *mutex);
-
-int rtems_gxx_mutex_destroy (__gthread_mutex_t *mutex);
-
-int rtems_gxx_mutex_trylock (__gthread_mutex_t *mutex);
-
-int rtems_gxx_mutex_unlock (__gthread_mutex_t *mutex);
-
-void rtems_gxx_recursive_mutex_init(__gthread_recursive_mutex_t *mutex);
-
-int rtems_gxx_recursive_mutex_lock(__gthread_recursive_mutex_t *mutex);
-
-int rtems_gxx_recursive_mutex_trylock(__gthread_recursive_mutex_t *mutex);
-
-int rtems_gxx_recursive_mutex_unlock(__gthread_recursive_mutex_t *mutex);
-
-#ifdef __cplusplus
-}
-#endif /* __cplusplus */
-
-#endif /* __GCC_WRAPPERS_h */
diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 65cac29500..4054e21253 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -188,8 +188,8 @@ typedef enum {
   /* INTERNAL_ERROR_THREAD_QUEUE_ENQUEUE_FROM_BAD_STATE = 18, */
   /* INTERNAL_ERROR_UNLIMITED_AND_MAXIMUM_IS_0 = 19, */
   /* INTERNAL_ERROR_SHUTDOWN_WHEN_NOT_UP = 20, */
-  INTERNAL_ERROR_GXX_KEY_ADD_FAILED = 21,
-  INTERNAL_ERROR_GXX_MUTEX_INIT_FAILED = 22,
+  /* INTERNAL_ERROR_GXX_KEY_ADD_FAILED = 21, */
+  /* INTERNAL_ERROR_GXX_MUTEX_INIT_FAILED = 22, */
   INTERNAL_ERROR_NO_MEMORY_FOR_HEAP = 23,
   INTERNAL_ERROR_CPU_ISR_INSTALL_VECTOR = 24,
   INTE

Re: [PATCH] Remove obsolete rtems_gxx_*() implementation

2022-01-26 Thread Joel Sherrill
Looks ok to me especially since it doesn't appear to add anything. :)

--joel

On Wed, Jan 26, 2022 at 4:05 AM Sebastian Huber
 wrote:
>
> GCC versions prior to 6.1 used a RTEMS thread model based on
> rtems_gxx_*() functions. GCC version 6.1 or later uses the
> self-contained synchronization objects of Newlib  for the
> RTEMS thread model.
>
> Remove the obsolete implementation.
>
> Close #3143.
> ---
>  cpukit/include/rtems/gxx_wrappers.h |  80 --
>  cpukit/include/rtems/score/interr.h |   4 +-
>  cpukit/libcsupport/src/gxx_wrappers.c   | 261 
>  spec/build/testsuites/libtests/grp.yml  |   2 -
>  spec/build/testsuites/libtests/gxx01.yml|  19 --
>  spec/build/testsuites/sptests/grp.yml   |   4 -
>  spec/build/testsuites/sptests/spfatal24.yml |  19 --
>  spec/build/testsuites/sptests/spfatal25.yml |  19 --
>  testsuites/libtests/gxx01/gxx01.doc |  33 ---
>  testsuites/libtests/gxx01/gxx01.scn |  35 ---
>  testsuites/libtests/gxx01/init.c| 228 -
>  testsuites/sptests/spfatal24/init.c |  31 ---
>  testsuites/sptests/spfatal24/spfatal24.doc  |  19 --
>  testsuites/sptests/spfatal24/spfatal24.scn  |   3 -
>  testsuites/sptests/spfatal25/init.c |  33 ---
>  testsuites/sptests/spfatal25/spfatal25.doc  |  19 --
>  testsuites/sptests/spfatal25/spfatal25.scn  |   3 -
>  17 files changed, 2 insertions(+), 810 deletions(-)
>  delete mode 100644 cpukit/include/rtems/gxx_wrappers.h
>  delete mode 100644 cpukit/libcsupport/src/gxx_wrappers.c
>  delete mode 100644 spec/build/testsuites/libtests/gxx01.yml
>  delete mode 100644 spec/build/testsuites/sptests/spfatal24.yml
>  delete mode 100644 spec/build/testsuites/sptests/spfatal25.yml
>  delete mode 100644 testsuites/libtests/gxx01/gxx01.doc
>  delete mode 100644 testsuites/libtests/gxx01/gxx01.scn
>  delete mode 100644 testsuites/libtests/gxx01/init.c
>  delete mode 100644 testsuites/sptests/spfatal24/init.c
>  delete mode 100644 testsuites/sptests/spfatal24/spfatal24.doc
>  delete mode 100644 testsuites/sptests/spfatal24/spfatal24.scn
>  delete mode 100644 testsuites/sptests/spfatal25/init.c
>  delete mode 100644 testsuites/sptests/spfatal25/spfatal25.doc
>  delete mode 100644 testsuites/sptests/spfatal25/spfatal25.scn
>
> diff --git a/cpukit/include/rtems/gxx_wrappers.h 
> b/cpukit/include/rtems/gxx_wrappers.h
> deleted file mode 100644
> index e462d27d66..00
> --- a/cpukit/include/rtems/gxx_wrappers.h
> +++ /dev/null
> @@ -1,80 +0,0 @@
> -/**
> - * @file
> - *
> - * RTEMS threads compatibility routines for libgcc2.
> - */
> -
> -/*
> - *  by: Rosimildo da Silva (rdasi...@connecttel.com)
> - *
> - *  Used ideas from:
> - *W. Eric Norum
> - *Canadian Light Source
> - *University of Saskatchewan
> - *Saskatoon, Saskatchewan, CANADA
> - *e...@cls.usask.ca
> - *
> - *  Eric sent some e-mail in the rtems-list as a start point for this
> - *  module implementation.
> - */
> -
> -#ifndef __GCC_WRAPPERS_h
> -#define __GCC_WRAPPERS_h
> -
> -#ifdef __cplusplus
> -extern "C" {
> -#endif /* __cplusplus */
> -
> -/**
> - *  @defgroup GxxWrappersSupport Gxx Wrappers Support
> - *
> - *  @ingroup libcsupport
> - *
> - *  @brief RTEMS Threads Compatibility Routines for Libgcc2
> - */
> -
> -/*
> - * These typedefs should match with the ones defined in the file
> - * gcc/gthr-rtems.h in the gcc distribution.
> - */
> -typedef void *__gthread_key_t;
> -typedef int   __gthread_once_t;
> -typedef void *__gthread_mutex_t;
> -typedef void *__gthread_recursive_mutex_t;
> -
> -int rtems_gxx_once(__gthread_once_t *once, void (*func) (void));
> -
> -int rtems_gxx_key_create (__gthread_key_t *key, void (*dtor) (void *));
> -
> -int rtems_gxx_key_delete (__gthread_key_t key);
> -
> -void *rtems_gxx_getspecific(__gthread_key_t key);
> -
> -int rtems_gxx_setspecific(__gthread_key_t key, const void *ptr);
> -
> -/*
> - * MUTEX support
> - */
> -void rtems_gxx_mutex_init (__gthread_mutex_t *mutex);
> -
> -int rtems_gxx_mutex_lock (__gthread_mutex_t *mutex);
> -
> -int rtems_gxx_mutex_destroy (__gthread_mutex_t *mutex);
> -
> -int rtems_gxx_mutex_trylock (__gthread_mutex_t *mutex);
> -
> -int rtems_gxx_mutex_unlock (__gthread_mutex_t *mutex);
> -
> -void rtems_gxx_recursive_mutex_init(__gthread_recursive_mutex_t *mutex);
> -
> -int rtems_gxx_recursive_mutex_lock(__gthread_recursive_mutex_t *mutex);
> -
> -int rtems_gxx_recursive_mutex_trylock(__gthread_recursive_mutex_t *mutex);
> -
> -int rtems_gxx_recursive_mutex_unlock(__gthread_recursive_mutex_t *mutex);
> -
> -#ifdef __cplusplus
> -}
> -#endif /* __cplusplus */
> -
> -#endif /* __GCC_WRAPPERS_h */
> diff --git a/cpukit/include/rtems/score/interr.h 
> b/cpukit/include/rtems/score/interr.h
> index 65cac29500..4054e21253 100644
> --- a/cpukit/include/rtems/score/interr.h
> +++ b/cpukit/include/rtems/score/interr.h
> @@ -188,8 +188,8 @@ typedef enum {
>/* INTERNAL_ERROR_THREAD_QUEUE_ENQUEUE_FROM_BAD_STATE

[PATCH] cpukit: Prevent error with disabled stack checker

2022-01-26 Thread Kinsey Moore
When the stack checker is not enabled, the stack checker reporting
function can still be called. This prevents that call from performing a
null memory access in trying to find the high water mark if the stack
checker was never initialized.

This also introduces a test to ensure this call does not cause a crash.

Closes #4588
---
 cpukit/libmisc/stackchk/check.c   |  6 ++
 spec/build/testsuites/libtests/grp.yml|  2 +
 spec/build/testsuites/libtests/stackchk02.yml | 19 ++
 testsuites/libtests/stackchk02/init.c | 67 +++
 testsuites/libtests/stackchk02/stackchk02.doc | 16 +
 testsuites/libtests/stackchk02/stackchk02.scn |  4 ++
 6 files changed, 114 insertions(+)
 create mode 100644 spec/build/testsuites/libtests/stackchk02.yml
 create mode 100644 testsuites/libtests/stackchk02/init.c
 create mode 100644 testsuites/libtests/stackchk02/stackchk02.doc
 create mode 100644 testsuites/libtests/stackchk02/stackchk02.scn

diff --git a/cpukit/libmisc/stackchk/check.c b/cpukit/libmisc/stackchk/check.c
index a2b63345d9..9119f8d940 100644
--- a/cpukit/libmisc/stackchk/check.c
+++ b/cpukit/libmisc/stackchk/check.c
@@ -487,6 +487,12 @@ void rtems_stack_checker_report_usage_with_plugin(
   uint32_t cpu_max;
   uint32_t cpu_index;
 
+  /* Make sure that the stack checker is enabled */
+  if ( Stack_check_Interrupt_stack[ 0 ].area == NULL ) {
+rtems_printf(printer, "RTEMS Stack Checker not enabled\n");
+return;
+  }
+
   rtems_printf(
  printer,
  " STACK USAGE BY THREAD\n"
diff --git a/spec/build/testsuites/libtests/grp.yml 
b/spec/build/testsuites/libtests/grp.yml
index cd5cc210e2..4717081312 100644
--- a/spec/build/testsuites/libtests/grp.yml
+++ b/spec/build/testsuites/libtests/grp.yml
@@ -249,6 +249,8 @@ links:
   uid: stackchk
 - role: build-dependency
   uid: stackchk01
+- role: build-dependency
+  uid: stackchk02
 - role: build-dependency
   uid: stat
 - role: build-dependency
diff --git a/spec/build/testsuites/libtests/stackchk02.yml 
b/spec/build/testsuites/libtests/stackchk02.yml
new file mode 100644
index 00..4a4cbf9660
--- /dev/null
+++ b/spec/build/testsuites/libtests/stackchk02.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2022 On-Line Applications Research (OAR)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/libtests/stackchk02/init.c
+stlib: []
+target: testsuites/libtests/stackchk02.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/libtests/stackchk02/init.c 
b/testsuites/libtests/stackchk02/init.c
new file mode 100644
index 00..0904e37c68
--- /dev/null
+++ b/testsuites/libtests/stackchk02/init.c
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup libtests
+ */
+
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#define CONFIGURE_INIT
+
+#include 
+
+#define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
+#define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
+
+#define TASK_STACK_SIZE (RTEMS_MINIMUM_STACK_SIZE*3)
+
+#define CONFIGURE_MAXIMUM_TASKS   1
+
+#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
+
+#include 
+
+#include 
+
+const char rtems_test_name[] = "STACKCHK02";
+
+rtems_task Init(
+  rtems_task_argument argument
+)
+{
+  TEST_BEGIN();
+
+  rtems_stack_checker_report_usage();
+
+  TEST_END();
+  rtems_test_exit( 0 );
+}
diff --git a/testsuites/libtest

Re: New validation test suites

2022-01-26 Thread Chris Johns
On 25/1/22 5:37 pm, Sebastian Huber wrote:
> On 25/01/2022 01:09, Chris Johns wrote:
>> On 25/1/22 1:39 am, Sebastian Huber wrote:
>>> how do we want to proceed with the integration of the new validation test 
>>> suite?
>>> At the moment it is not clear to me what issues are left to resolve and 
>>> what I
>>> can do to address them?
>>
>> I believe I have been clear about what I see as being needed:
>>
>> https://lists.rtems.org/pipermail/devel/2022-January/070323.html
> 
> Sorry, I don't know what I have to do next.

Sure and I am sorry if this was not clear.

> The release process for rtems-central is quite clear from my point of view. 

I would not have raised this if I was in the same position. You are the only
person I know who understand rtems-central. I only have an overview of it and I
I am sorry but I have no spare time in invest in learning more about it. I do
have the responsibility of releasing RTEMS and if I accept these changes without
any of the needed support in place history has taught me I am left to provide
it. Tools and scripts that shows how a process is to work would go a long long
way to resolving this issue.

The RTEMS Release repo is a series of FreeBSD scripts I use to release ...

https://git.rtems.org/rtems-release/

I have not touched it in a while and it needs work to change it to support waf.

> We just have to create a
> release branch for RTEMS 6 and reference release branch commits in the 
> submodules.

How do you validate the generated sources in the sub-modules match those in the
branched submodules? I think this should be done as part of the release
procedure to catch any mistakes.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: New validation test suites

2022-01-26 Thread Sebastian Huber

On 27/01/2022 03:24, Chris Johns wrote:

On 25/1/22 5:37 pm, Sebastian Huber wrote:

On 25/01/2022 01:09, Chris Johns wrote:

On 25/1/22 1:39 am, Sebastian Huber wrote:

how do we want to proceed with the integration of the new validation test suite?
At the moment it is not clear to me what issues are left to resolve and what I
can do to address them?


I believe I have been clear about what I see as being needed:

https://lists.rtems.org/pipermail/devel/2022-January/070323.html


Sorry, I don't know what I have to do next.


Sure and I am sorry if this was not clear.


The release process for rtems-central is quite clear from my point of view.


I would not have raised this if I was in the same position. You are the only
person I know who understand rtems-central. I only have an overview of it and I
I am sorry but I have no spare time in invest in learning more about it. I do
have the responsibility of releasing RTEMS and if I accept these changes without
any of the needed support in place history has taught me I am left to provide
it. Tools and scripts that shows how a process is to work would go a long long
way to resolving this issue.

The RTEMS Release repo is a series of FreeBSD scripts I use to release ...

https://git.rtems.org/rtems-release/

I have not touched it in a while and it needs work to change it to support waf.


Ok, I will update

https://docs.rtems.org/branches/master/eng/release-process.html

to account for rtems-central.git.

It seems that there is some work to do to make an RTEMS 6.1 release 
happen in general (this issue is independent of the new validation 
tests). We should figure out which core developers can contribute what.





We just have to create a
release branch for RTEMS 6 and reference release branch commits in the 
submodules.


How do you validate the generated sources in the sub-modules match those in the
branched submodules? I think this should be done as part of the release
procedure to catch any mistakes.


I will write something about this in the release procedure documentation.

--
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] cpukit: Prevent error with disabled stack checker

2022-01-26 Thread Sebastian Huber

On 26/01/2022 23:07, Kinsey Moore wrote:

diff --git a/cpukit/libmisc/stackchk/check.c b/cpukit/libmisc/stackchk/check.c
index a2b63345d9..9119f8d940 100644
--- a/cpukit/libmisc/stackchk/check.c
+++ b/cpukit/libmisc/stackchk/check.c
@@ -487,6 +487,12 @@ void rtems_stack_checker_report_usage_with_plugin(
uint32_t cpu_max;
uint32_t cpu_index;
  
+  /* Make sure that the stack checker is enabled */

+  if ( Stack_check_Interrupt_stack[ 0 ].area == NULL ) {
+rtems_printf(printer, "RTEMS Stack Checker not enabled\n");
+return;
+  }
+
rtems_printf(
   printer,
   " STACK USAGE BY THREAD\n"


This check is insufficient in SMP configurations. It also prevents a 
stack report without the stack usage information.


I would move the check to Stack_check_Dump_stack_usage(). Simply report 
nothing if stack == NULL.


--
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