date:20170915

Re: Loading a driver in RTEMS

2017-09-15 Thread Sebastian Huber


On 14/09/17 14:24, sangeetha...@gracelabs.com wrote:

I have successfully compiled a newly written sample driver in 
RTEMS(sample.o is created). Can anyone tell me how to load this 
driver. How can I see the print statements I have given??


Which API did you use for this device driver?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Loading a driver in RTEMS

2017-09-15 Thread akshaya




On Friday 15 September 2017 02:00 PM, Sebastian Huber wrote:

On 14/09/17 14:24, sangeetha...@gracelabs.com wrote:

I have successfully compiled a newly written sample driver in 
RTEMS(sample.o is created). Can anyone tell me how to load this 
driver. How can I see the print statements I have given??


Which API did you use for this device driver?



--
Thanks and Regards

Akshaya.P.C

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

[PATCH] libio: Remove rtems_libio_t::driver

2017-09-15 Thread Sebastian Huber

This member was apparently unused.

Close #3133.
---
 cpukit/libcsupport/include/rtems/libio.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cpukit/libcsupport/include/rtems/libio.h 
b/cpukit/libcsupport/include/rtems/libio.h
index 804929915a..9d30dafddf 100644
--- a/cpukit/libcsupport/include/rtems/libio.h
+++ b/cpukit/libcsupport/include/rtems/libio.h
@@ -1318,7 +1318,6 @@ extern const rtems_filesystem_limits_and_options_t
  * to (eg: offset, driver, pathname should be in that)
  */
 struct rtems_libio_tt {
-  rtems_driver_name_t*driver;
   off_t   offset;/* current offset into 
file */
   Atomic_Uint flags;
   rtems_filesystem_location_info_tpathinfo;
-- 
2.12.3

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

[PATCH 1/3] posix: Allow PTHREAD_PROCESS_SHARED for mutexes

2017-09-15 Thread Sebastian Huber

Close #3125.
---
 cpukit/posix/include/rtems/posix/posixapi.h | 15 +++
 cpukit/posix/src/mutexinit.c| 10 +++---
 testsuites/psxtests/psx05/init.c|  9 ++---
 testsuites/psxtests/psx05/psx05.scn |  2 +-
 4 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/cpukit/posix/include/rtems/posix/posixapi.h 
b/cpukit/posix/include/rtems/posix/posixapi.h
index 1a64cf7a1d..2441a2ee6f 100644
--- a/cpukit/posix/include/rtems/posix/posixapi.h
+++ b/cpukit/posix/include/rtems/posix/posixapi.h
@@ -26,6 +26,8 @@
 #include 
 #include 
 
+#include 
+
 /**
  * @defgroup POSIXAPI RTEMS POSIX API
  *
@@ -125,6 +127,19 @@ RTEMS_INLINE_ROUTINE int 
_POSIX_Zero_or_minus_one_plus_errno(
   } \
   return (type *) the_object
 
+/*
+ * See also The Open Group Base Specifications Issue 7, IEEE Std 1003.1-2008,
+ * 2016 Edition, subsection 2.9.9, Synchronization Object Copies and
+ * Alternative Mappings.
+ *
+ * 
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_09
+ */
+RTEMS_INLINE_ROUTINE bool _POSIX_Is_valid_pshared( int pshared )
+{
+  return pshared == PTHREAD_PROCESS_PRIVATE ||
+pshared == PTHREAD_PROCESS_SHARED;
+}
+
 /** @} */
 
 #endif
diff --git a/cpukit/posix/src/mutexinit.c b/cpukit/posix/src/mutexinit.c
index 08acb539b5..c7161b0daf 100644
--- a/cpukit/posix/src/mutexinit.c
+++ b/cpukit/posix/src/mutexinit.c
@@ -19,6 +19,7 @@
 #endif
 
 #include 
+#include 
 #include 
 #include 
 
@@ -62,14 +63,9 @@ int pthread_mutex_init(
   if ( !the_attr->is_initialized )
 return EINVAL;
 
-  /*
-   *  We only support process private mutexes.
-   */
-  if ( the_attr->process_shared == PTHREAD_PROCESS_SHARED )
-return ENOSYS;
-
-  if ( the_attr->process_shared != PTHREAD_PROCESS_PRIVATE )
+  if ( !_POSIX_Is_valid_pshared( the_attr->process_shared ) ) {
 return EINVAL;
+  }
 
   /*
*  Determine the discipline of the mutex
diff --git a/testsuites/psxtests/psx05/init.c b/testsuites/psxtests/psx05/init.c
index cde8733bb0..e524d6f96f 100644
--- a/testsuites/psxtests/psx05/init.c
+++ b/testsuites/psxtests/psx05/init.c
@@ -429,10 +429,13 @@ void *POSIX_Init(
   status = pthread_mutexattr_init( &attr );
   rtems_test_assert( !status );
 
-  puts( "Init: pthread_mutex_init - ENOSYS (process wide scope)" );
-  attr.process_shared = PTHREAD_PROCESS_SHARED;
+  puts( "Init: pthread_mutex_init - process shared scope" );
+  status = pthread_mutexattr_setpshared( &attr, PTHREAD_PROCESS_SHARED );
+  rtems_test_assert( status == 0 );
   status = pthread_mutex_init( &Mutex_id, &attr );
-  rtems_test_assert( status == ENOSYS );
+  rtems_test_assert( status == 0 );
+  status = pthread_mutex_destroy( &Mutex_id );
+  rtems_test_assert( status == 0 );
 
   puts( "Init: pthread_mutex_init - EINVAL (invalid scope)" );
   attr.process_shared = -1;
diff --git a/testsuites/psxtests/psx05/psx05.scn 
b/testsuites/psxtests/psx05/psx05.scn
index 4e66ceabf6..0315eee562 100644
--- a/testsuites/psxtests/psx05/psx05.scn
+++ b/testsuites/psxtests/psx05/psx05.scn
@@ -37,7 +37,7 @@ Init: pthread_mutexattr_setprotocol - SUCCESSFUL
 Init: pthread_mutexattr_setprioceiling - SUCCESSFUL
 Init: pthread_mutex_init - EINVAL (bad priority ceiling)
 Init: Resetting mutex attributes
-Init: pthread_mutex_init - ENOSYS (process wide scope)
+Init: pthread_mutex_init - process shared scope
 Init: pthread_mutex_init - EINVAL (invalid scope)
 Init: pthread_mutex_init - EINVAL (invalid type)
 Init: Resetting mutex attributes
-- 
2.12.3

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

[PATCH 2/3] posix: Allow PTHREAD_PROCESS_SHARED for barriers

2017-09-15 Thread Sebastian Huber

Close #3126.
---
 cpukit/posix/src/pbarrierinit.c   |  9 +++--
 testsuites/psxtests/psxbarrier01/psxbarrier01.scn |  8 ++--
 testsuites/psxtests/psxbarrier01/test.c   | 17 +
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/cpukit/posix/src/pbarrierinit.c b/cpukit/posix/src/pbarrierinit.c
index 956085658b..c14cc0cb90 100644
--- a/cpukit/posix/src/pbarrierinit.c
+++ b/cpukit/posix/src/pbarrierinit.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  *  pthread_barrier_init
@@ -78,12 +79,8 @@ int pthread_barrier_init(
   if ( !the_attr->is_initialized )
 return EINVAL;
 
-  switch ( the_attr->process_shared ) {
-case PTHREAD_PROCESS_PRIVATE:/* only supported values */
-  break;
-case PTHREAD_PROCESS_SHARED:
-default:
-  return EINVAL;
+  if ( !_POSIX_Is_valid_pshared( the_attr->process_shared ) ) {
+return EINVAL;
   }
 
   /*
diff --git a/testsuites/psxtests/psxbarrier01/psxbarrier01.scn 
b/testsuites/psxtests/psxbarrier01/psxbarrier01.scn
index 6b714115ae..d568d8d03e 100644
--- a/testsuites/psxtests/psxbarrier01/psxbarrier01.scn
+++ b/testsuites/psxtests/psxbarrier01/psxbarrier01.scn
@@ -1,4 +1,4 @@
-*** POSIX BARRIER TEST 01 ***
+*** BEGIN OF TEST PSXBARRIER 1 ***
 pthread_barrierattr_init( NULL ) -- EINVAL
 pthread_barrierattr_setpshared( NULL, private ) -- EINVAL
 pthread_barrierattr_setpshared( NULL, shared ) -- EINVAL
@@ -19,6 +19,10 @@ pthread_barrier_init( NULL, NULL, 2 ) -- EINVAL
 pthread_barrier_init( &barrier, &attr, 2 ) -- EINVAL
 pthread_barrierattr_init( &attr ) -- OK
 pthread_barrier_init( &barrier, &attr, 0 ) -- EINVAL
+pthread_barrier_init( &barrier, &attr, 1 ) -- EINVAL
+pthread_barrierattr_setpshared( &attr, shared ) -- OK
+pthread_barrier_init( &barrier, &attr, 1 ) -- OK
+pthread_barrier_destroy( &barrier ) -- OK
 pthread_barrier_init( &barrier, NULL, 1 ) -- OK
 pthread_barrier_init( &barrier, NULL, 1 ) -- EAGAIN
 pthread_barrier_destroy( &barrier ) -- OK
@@ -38,4 +42,4 @@ Init: pthread_create - thread 2 OK
 pthread_barrier_wait( &Barrier ) for thread 0x0b010002
 pthread_barrier_wait - 0x0b010002 released
 pthread_barrier_wait - 0x0b010001 released
-*** END OF POSIX BARRIER TEST 01 ***
+*** END OF TEST PSXBARRIER 1 ***
diff --git a/testsuites/psxtests/psxbarrier01/test.c 
b/testsuites/psxtests/psxbarrier01/test.c
index bcbb87a467..16e8665b94 100644
--- a/testsuites/psxtests/psxbarrier01/test.c
+++ b/testsuites/psxtests/psxbarrier01/test.c
@@ -161,6 +161,23 @@ int main(
   status = pthread_barrier_init( &barrier, &attr, 0 );
   rtems_test_assert( status == EINVAL );
 
+  puts( "pthread_barrier_init( &barrier, &attr, 1 ) -- EINVAL" );
+  attr.process_shared = -1;
+  status = pthread_barrier_init( &barrier, &attr, 1 );
+  rtems_test_assert( status == EINVAL );
+
+  puts( "pthread_barrierattr_setpshared( &attr, shared ) -- OK" );
+  status = pthread_barrierattr_setpshared( &attr, PTHREAD_PROCESS_SHARED );
+  rtems_test_assert( status == 0 );
+
+  puts( "pthread_barrier_init( &barrier, &attr, 1 ) -- OK" );
+  status = pthread_barrier_init( &barrier, &attr, 1 );
+  rtems_test_assert( status == 0 );
+
+  puts( "pthread_barrier_destroy( &barrier ) -- OK" );
+  status = pthread_barrier_destroy( &barrier );
+  rtems_test_assert( status == 0 );
+
   /* allocating too many */
   puts( "pthread_barrier_init( &barrier, NULL, 1 ) -- OK" );
   status = pthread_barrier_init( &barrier, NULL, 1 );
-- 
2.12.3

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

[PATCH 3/3] posix: Allow PTHREAD_PROCESS_SHARED for condvar

2017-09-15 Thread Sebastian Huber

Close #3137.
---
 cpukit/posix/src/condinit.c |  7 +--
 testsuites/psxtests/psx10/init.c| 19 +++
 testsuites/psxtests/psx10/psx10.scn | 12 ++--
 3 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/cpukit/posix/src/condinit.c b/cpukit/posix/src/condinit.c
index e863dcd183..8d3aa8e244 100644
--- a/cpukit/posix/src/condinit.c
+++ b/cpukit/posix/src/condinit.c
@@ -19,6 +19,7 @@
 #endif
 
 #include 
+#include 
 
 /**
  *  11.4.2 Initializing and Destroying a Condition Variable,
@@ -38,12 +39,14 @@ int pthread_cond_init(
   /*
*  Be careful about attributes when global!!!
*/
-  if ( the_attr->process_shared == PTHREAD_PROCESS_SHARED )
-return EINVAL;
 
   if ( !the_attr->is_initialized )
 return EINVAL;
 
+  if ( !_POSIX_Is_valid_pshared( the_attr->process_shared ) ) {
+return EINVAL;
+  }
+
   the_cond = _POSIX_Condition_variables_Allocate();
 
   if ( !the_cond ) {
diff --git a/testsuites/psxtests/psx10/init.c b/testsuites/psxtests/psx10/init.c
index a37e14efba..24265ba0ad 100644
--- a/testsuites/psxtests/psx10/init.c
+++ b/testsuites/psxtests/psx10/init.c
@@ -115,6 +115,25 @@ void *POSIX_Init(
   rtems_test_assert( status == EINVAL );
   puts( "Init: pthread_cond_destroy - EINVAL (cond invalid)" );
 
+/* pshared tests */
+
+  puts( "Init: pthread_cond_init - EINVAL (invalid pshared)" );
+  attr.process_shared = -1;
+  status = pthread_cond_init( &cond, &attr );
+  rtems_test_assert( status == EINVAL );
+
+  puts( "Init: pthread_condattr_setpshared - PTHREAD_PROCESS_SHARED" );
+  status = pthread_condattr_setpshared( &attr, PTHREAD_PROCESS_SHARED );
+  rtems_test_assert( status == 0 );
+
+  puts( "Init: pthread_cond_init - OK" );
+  status = pthread_cond_init( &cond, &attr );
+  rtems_test_assert( status == 0 );
+
+  puts( "Init: pthread_cond_destroy - OK" );
+  status = pthread_cond_destroy( &cond );
+  rtems_test_assert( status == 0 );
+
 /* initiailize the attribute for the rest of the test */
 
   puts( "Init: pthread_cond_init - attr" );
diff --git a/testsuites/psxtests/psx10/psx10.scn 
b/testsuites/psxtests/psx10/psx10.scn
index 962540d6e4..2c70df8713 100644
--- a/testsuites/psxtests/psx10/psx10.scn
+++ b/testsuites/psxtests/psx10/psx10.scn
@@ -1,4 +1,4 @@
-*** POSIX TEST 10 ***
+*** BEGIN OF TEST PSX 10 ***
 Init: pthread_condattr_init
 Init: pthread_condattr_init - EINVAL (attribute invalid)
 Init: pthread_condattr_destroy
@@ -15,12 +15,18 @@ Init: pthread_cond_init - EINVAL (attr not initialized)
 Init: pthread_cond_init - ENOMEM (too many conds)
 Init: pthread_cond_destroy
 Init: pthread_cond_destroy - EINVAL (cond invalid)
+Init: pthread_cond_init - EINVAL (invalid pshared)
+Init: pthread_condattr_setpshared - PTHREAD_PROCESS_SHARED
+Init: pthread_cond_init - OK
+Init: pthread_cond_destroy - OK
 Init: pthread_cond_init - attr
+
 Init: sleep to switch to Task_1
 Task_1: ID is 0x0b010002
 Task_1: pthread_cond_wait
 Init: pthread_cond_destroy - EBUSY (task1 waiting)
 Init: pthread_cond_signal
+
 Init: sleep - switch to Task_1 and Task_2
 Task_1: back from pthread_cond_wait release mutex
 Task_1: pthread_cond_wait
@@ -34,6 +40,7 @@ Task_2: back from pthread_cond_wait release mutex
 Task_2: task exit
 Init: pthread_cond_timedwait for 3 seconds
 Init: pthread_cond_timedwait - ETIMEDOUT - (mutex not acquired)
+
 Init: pthread_cond_signal - EINVAL (cond invalid)
 Init: pthread_cond_broadcast - EINVAL (cond invalid)
 Init: pthread_cond_wait - EINVAL (cond invalid)
@@ -45,6 +52,7 @@ Init: pthread_cond_timedwait - ETIMEDOUT (abstime->tv_sec < 
current time)
 Init: pthread_cond_timedwait - ETIMEDOUT (abstime->tv_nsec < current time)
 Init: pthread_cond_wait - EINVAL (mutex not locked before call)
 Init: pthread_cond_timedwait - EINVAL (mutex not locked before call)
+
 Init: sleep - switch to Task_3
 Task_3: ID is 0x0b010004
 Task_3: pthread_cond_wait
@@ -52,4 +60,4 @@ Init: pthread_cond_signal
 Init: sleep - switch to Task_3
 Task_3: pthread_cond_wait - EINVAL (mutex not locked after signal)
 Task_3: task exit
-*** END OF POSIX TEST 10 ***
+*** END OF TEST PSX 10 ***
-- 
2.12.3

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

Self-contained POSIX synchronization objects for RTEMS 4.12?

2017-09-15 Thread Sebastian Huber


Hello,

the next Newlib snapshot will introduce a 64-bit time_t which makes this 
tool chain ABI incompatible to all previous versions and forces a 
re-compilation of all object files (RTEMS, libraries, applications). 
This would be a good opportunity to also introduce the self-contained 
POSIX synchronization objects:


https://devel.rtems.org/ticket/3112

https://devel.rtems.org/ticket/3113

https://devel.rtems.org/ticket/3114

https://devel.rtems.org/ticket/3115

https://devel.rtems.org/ticket/3116

What do you think about this? Anyway we should make the RTEMS 4.12 
branch with the next Newlib snapshot.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: IOP changes impact on IPV4 Stack

2017-09-15 Thread Sebastian Huber


Hello Joel,


On 15/09/17 01:41, Joel Sherrill wrote:

Hi Sebastian

The IPV4 stack allocates IOPs and maps fds to sockets
in its implementation of system calls. Are these impacted
by the recent changes?

If so, you need to make sure to fix the handful of files
impacted.


thanks for the reminder. Yes, I had to adjust a couple of things in the 
old and new network stack.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: IOP changes impact on IPV4 Stack

2017-09-15 Thread Joel Sherrill

I haven't poured through the batch of email this morning. Are the changes
in this set?

Is there anywhere else this applies? Shared memory uses fds.

On Sep 15, 2017 8:02 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
>
> On 15/09/17 01:41, Joel Sherrill wrote:
>
>> Hi Sebastian
>>
>> The IPV4 stack allocates IOPs and maps fds to sockets
>> in its implementation of system calls. Are these impacted
>> by the recent changes?
>>
>> If so, you need to make sure to fix the handful of files
>> impacted.
>>
>
> thanks for the reminder. Yes, I had to adjust a couple of things in the
> old and new network stack.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: IOP changes impact on IPV4 Stack

2017-09-15 Thread Sebastian Huber


On 15/09/17 15:12, Joel Sherrill wrote:

I haven't poured through the batch of email this morning. Are the 
changes in this set?




I checked in the all patches today including the one for libbsd:

https://devel.rtems.org/ticket/3132

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: IOP changes impact on IPV4 Stack

2017-09-15 Thread Sebastian Huber


On 15/09/17 15:15, Sebastian Huber wrote:


On 15/09/17 15:12, Joel Sherrill wrote:

I haven't poured through the batch of email this morning. Are the 
changes in this set?




I checked in the all patches today including the one for libbsd:

https://devel.rtems.org/ticket/3132



You can now interrupt a open() followed by close() sequence at an 
arbitrary point and perform an operation on this file descriptor without 
crashing the system:


https://git.rtems.org/rtems/tree/testsuites/sptests/spintrcritical24/init.c#n70

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Self-contained POSIX synchronization objects for RTEMS 4.12?

2017-09-15 Thread Joel Sherrill

On Fri, Sep 15, 2017 at 7:56 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the next Newlib snapshot will introduce a 64-bit time_t which makes this
> tool chain ABI incompatible to all previous versions and forces a
> re-compilation of all object files (RTEMS, libraries, applications). This
> would be a good opportunity to also introduce the self-contained POSIX
> synchronization objects:
>
> https://devel.rtems.org/ticket/3112
>
> https://devel.rtems.org/ticket/3113
>
> https://devel.rtems.org/ticket/3114
>
> https://devel.rtems.org/ticket/3115
>
> https://devel.rtems.org/ticket/3116
>
> What do you think about this? Anyway we should make the RTEMS 4.12 branch
> with the next Newlib snapshot.
>

4.12 should have 64 bit time_t no questions about it.

I am ok with the self-contained POSIX objects going in.

But in general, we just need to work the open 4.12 tickets. There is
still a pile to work through or defer.

--joel


>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4
> , D-82178
> Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> 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: LLVM/clang status?

2017-09-15 Thread Daniel Hellstrom


Hi,

We did submit some SPARC patches to make RTEMS compile with LLVM during 
May. One of the patches which was not accepted I believe Sebastian 
updated and pushed during end of July. We have not made any attempts 
rebuilding since. At the time we ran the tests we were able to run most 
of the RTEMS test-suite with 20-25 failures or so if I recall correctly. 
However most of them was not dependent on LLVM and fixed since in the 
RTEMS repository, the others were fixed in the LLVM SPARC/LEON-REX 
backend. I recall that there were some potential problems with SPARC 
inline assembly in some cases when building for LEON-REX (no surprise 
since it is not the same ISA..). Also, we built newlib using LLVM. I'm 
not sure which kernel configurations we compiled for though.


Since May we distribute a LLVM-4.0 toolchain with our bare-metal 
environment. During the coming months we plan to release a LLVM 
toolchain together with RCC-1.3.x. However we have some work to do on 
the front-end for RTEMS first and testing of course. We will have some 
LLVM specific documentation once released.


Regards,
Daniel

On 2017-09-14 02:10, Joel Sherrill wrote:
Daniel Hellstrom should ready speak up. They have it working for 
SPARC. I don't know if anything special is needed for other targets so 
it should just be a matter of attempting it and seeing


On Sep 13, 2017 6:46 PM, "Gedare Bloom" > wrote:


I've seen some discussion about using clang to compile a few targets.
Is there any documentation about what is known to work/not work, and
any additional directions needed to be successful?

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


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

Re: LLVM/clang status?

2017-09-15 Thread Gedare Bloom

Ah, thanks for the update Daniel!

I recently saw someone on newlib mailing list say that the newlib can
be compiled by clang for the ARM processor now.

-Gedare

On Fri, Sep 15, 2017 at 10:33 AM, Daniel Hellstrom  wrote:
> Hi,
>
> We did submit some SPARC patches to make RTEMS compile with LLVM during May.
> One of the patches which was not accepted I believe Sebastian updated and
> pushed during end of July. We have not made any attempts rebuilding since.
> At the time we ran the tests we were able to run most of the RTEMS
> test-suite with 20-25 failures or so if I recall correctly. However most of
> them was not dependent on LLVM and fixed since in the RTEMS repository, the
> others were fixed in the LLVM SPARC/LEON-REX backend. I recall that there
> were some potential problems with SPARC inline assembly in some cases when
> building for LEON-REX (no surprise since it is not the same ISA..). Also, we
> built newlib using LLVM. I'm not sure which kernel configurations we
> compiled for though.
>
> Since May we distribute a LLVM-4.0 toolchain with our bare-metal
> environment. During the coming months we plan to release a LLVM toolchain
> together with RCC-1.3.x. However we have some work to do on the front-end
> for RTEMS first and testing of course. We will have some LLVM specific
> documentation once released.
>
> Regards,
> Daniel
>
>
> On 2017-09-14 02:10, Joel Sherrill wrote:
>
> Daniel Hellstrom should ready speak up. They have it working for SPARC. I
> don't know if anything special is needed for other targets so it should just
> be a matter of attempting it and seeing
>
> On Sep 13, 2017 6:46 PM, "Gedare Bloom"  wrote:
>>
>> I've seen some discussion about using clang to compile a few targets.
>> Is there any documentation about what is known to work/not work, and
>> any additional directions needed to be successful?
>>
>> -Gedare
>> ___
>> 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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Self-contained POSIX synchronization objects for RTEMS 4.12?

2017-09-15 Thread Chris Johns

On 16/9/17 12:14 am, Joel Sherrill wrote:
> On Fri, Sep 15, 2017 at 7:56 AM, Sebastian Huber
>  >
> wrote:
> 
> Anyway we should make the RTEMS 4.12 branch
> with the next Newlib snapshot.
> 
> But in general, we just need to work the open 4.12 tickets. There is
> still a pile to work through or defer.
> 

I have just raised #3138 and a branch cannot be considered until it is resolved.
I would prefer we have a clear run to a release from the branch point.

Amar and I have briefly discussed the solution of moving some of the jail data
to local TrueNAS mounts.

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

Re: Loading a driver in RTEMS

Re: Loading a driver in RTEMS

[PATCH] libio: Remove rtems_libio_t::driver

[PATCH 1/3] posix: Allow PTHREAD_PROCESS_SHARED for mutexes

[PATCH 2/3] posix: Allow PTHREAD_PROCESS_SHARED for barriers

[PATCH 3/3] posix: Allow PTHREAD_PROCESS_SHARED for condvar

Self-contained POSIX synchronization objects for RTEMS 4.12?

Re: IOP changes impact on IPV4 Stack

Re: IOP changes impact on IPV4 Stack

Re: IOP changes impact on IPV4 Stack

Re: IOP changes impact on IPV4 Stack

Re: Self-contained POSIX synchronization objects for RTEMS 4.12?

Re: LLVM/clang status?

Re: LLVM/clang status?

Re: Self-contained POSIX synchronization objects for RTEMS 4.12?

15 matches

Site Navigation

Mail list logo

Footer information