libbsd need --enable-posix any more?

[Chris Johns]

Hi,

LibBSD checks for --enable-posix. Is this check needed with rtems.git master?

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

Re: libbsd need --enable-posix any more?

[Sebastian Huber]

On 13/10/2020 10:06, Chris Johns wrote:


LibBSD checks for --enable-posix. Is this check needed with rtems.git master?

I haven't tried it out. It would be good to get rid of this requirement.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Remove implementation-specific inline functions with exactly one caller?

[Sebastian Huber]

Hello,

we have a couple of implementation-specific inline functions defined in 
header files which have exactly one caller. I think we should remove 
these functions in general, to reduce the lines of code, making code 
review easier, and reduce the number of functions which need 
documentation. If it makes the caller site more clear, then we should 
place them in the source file of the caller. Examples:


cpukit/rtems/src/partcreate.c:  the_partition = _Partition_Allocate();
cpukit/include/rtems/rtems/partimpl.h:RTEMS_INLINE_ROUTINE 
Partition_Control *_Partition_Allocate ( void )


cpukit/include/rtems/rtems/regionimpl.h:RTEMS_INLINE_ROUTINE bool 
_Region_Free_segment (
cpukit/rtems/src/regionreturnsegment.c:  if ( _Region_Free_segment( 
the_region, segment ) ) {


cpukit/sapi/src/extensiondelete.c:  the_extension = _Extension_Get( id );
cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE 
Extension_Control *_Extension_Get( Objects_Id id )


cpukit/sapi/src/extensioncreate.c:  the_extension = _Extension_Allocate();
cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE 
Extension_Control *_Extension_Allocate( void )


cpukit/sapi/src/extensiondelete.c:    _Extension_Free( the_extension );
cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE void 
_Extension_Free (


What do you think?

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

[PATCH] Remove *_Is_null() inline functions

[Sebastian Huber]

Simply compare the values against NULL.
---
 cpukit/include/rtems/chain.h|  2 +-
 cpukit/include/rtems/rtems/asrimpl.h| 13 -
 cpukit/include/rtems/score/chainimpl.h  | 17 -
 cpukit/include/rtems/score/objectmp.h   | 15 ---
 cpukit/include/rtems/score/threadimpl.h | 15 ---
 cpukit/rtems/src/msgmp.c|  5 +++--
 cpukit/rtems/src/partmp.c   |  5 +++--
 cpukit/rtems/src/semmp.c|  3 ++-
 cpukit/rtems/src/signalcatch.c  |  2 +-
 cpukit/rtems/src/signalsend.c   |  2 +-
 cpukit/rtems/src/taskconstruct.c|  2 +-
 cpukit/score/src/objectmp.c |  7 ---
 12 files changed, 16 insertions(+), 72 deletions(-)

diff --git a/cpukit/include/rtems/chain.h b/cpukit/include/rtems/chain.h
index 11ebdca322..25ea0b23b7 100644
--- a/cpukit/include/rtems/chain.h
+++ b/cpukit/include/rtems/chain.h
@@ -234,7 +234,7 @@ RTEMS_INLINE_ROUTINE bool rtems_chain_is_null_node(
   const rtems_chain_node *the_node
 )
 {
-  return _Chain_Is_null_node( the_node );
+  return the_node == NULL;
 }
 
 /**
diff --git a/cpukit/include/rtems/rtems/asrimpl.h 
b/cpukit/include/rtems/rtems/asrimpl.h
index 8e8efe5de5..90910cabc4 100644
--- a/cpukit/include/rtems/rtems/asrimpl.h
+++ b/cpukit/include/rtems/rtems/asrimpl.h
@@ -45,19 +45,6 @@ RTEMS_INLINE_ROUTINE void _ASR_Initialize (
   memset(asr, 0, sizeof(*asr));
 }
 
-/**
- *  @brief ASR_Is_null_handler
- *
- *  This function returns TRUE if the given asr_handler is NULL and
- *  FALSE otherwise.
- */
-RTEMS_INLINE_ROUTINE bool _ASR_Is_null_handler (
-  rtems_asr_entry asr_handler
-)
-{
-  return asr_handler == NULL;
-}
-
 RTEMS_INLINE_ROUTINE rtems_signal_set _ASR_Swap_signals( ASR_Information *asr )
 {
   rtems_signal_set new_signals_posted;
diff --git a/cpukit/include/rtems/score/chainimpl.h 
b/cpukit/include/rtems/score/chainimpl.h
index 15bce3668c..2d78c4ec6d 100644
--- a/cpukit/include/rtems/score/chainimpl.h
+++ b/cpukit/include/rtems/score/chainimpl.h
@@ -166,23 +166,6 @@ RTEMS_INLINE_ROUTINE bool _Chain_Are_nodes_equal(
   return left == right;
 }
 
-/**
- * @brief Checks if the chain node pointer is NULL.
- *
- * This function returns true if the_node is NULL and false otherwise.
- *
- * @param the_node The node pointer to check.
- *
- * @retval true @a the_node is @c NULL.
- * @retval false @a the_node is not @c NULL.
- */
-RTEMS_INLINE_ROUTINE bool _Chain_Is_null_node(
-  const Chain_Node *the_node
-)
-{
-  return (the_node == NULL);
-}
-
 /**
  * @brief Returns pointer to chain head.
  *
diff --git a/cpukit/include/rtems/score/objectmp.h 
b/cpukit/include/rtems/score/objectmp.h
index c2621c3857..74a01de1a7 100644
--- a/cpukit/include/rtems/score/objectmp.h
+++ b/cpukit/include/rtems/score/objectmp.h
@@ -190,21 +190,6 @@ Objects_MP_Control *_Objects_MP_Allocate_global_object( 
void );
  */
 void _Objects_MP_Free_global_object( Objects_MP_Control *the_object );
 
-/**
- * @brief Checks if the global object is NULL or not.
- *
- * @param the_object The object to check if it is NULL.
- *
- * @retval true @a the_object is NULL.
- * @retval false @a the_object is not NULL.
- */
-RTEMS_INLINE_ROUTINE bool _Objects_MP_Is_null_global_object (
-  Objects_MP_Control *the_object
-)
-{
-  return( the_object == NULL );
-}
-
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/include/rtems/score/threadimpl.h 
b/cpukit/include/rtems/score/threadimpl.h
index a2e1e1427c..9468d64df0 100644
--- a/cpukit/include/rtems/score/threadimpl.h
+++ b/cpukit/include/rtems/score/threadimpl.h
@@ -1071,21 +1071,6 @@ RTEMS_INLINE_ROUTINE bool 
_Thread_Is_context_switch_necessary( void )
   return ( _Thread_Dispatch_necessary );
 }
 
-/**
- * @brief Checks if the thread is NULL.
- *
- * @param the_thread The thread for the verification.
- *
- * @retval true The thread is @c NULL.
- * @retval false The thread is not @c NULL.
- */
-RTEMS_INLINE_ROUTINE bool _Thread_Is_null (
-  const Thread_Control *the_thread
-)
-{
-  return ( the_thread == NULL );
-}
-
 /**
  * @brief Gets the maximum number of internal threads.
  *
diff --git a/cpukit/rtems/src/msgmp.c b/cpukit/rtems/src/msgmp.c
index ae7c9802e2..9847cbd569 100644
--- a/cpukit/rtems/src/msgmp.c
+++ b/cpukit/rtems/src/msgmp.c
@@ -397,8 +397,9 @@ static void _Message_queue_MP_Process_packet (
 
   the_thread = _Thread_MP_Find_proxy( the_packet->proxy_id );
 
-  if (! _Thread_Is_null( the_thread ) )
- _Thread_queue_Extract( the_thread );
+  if ( the_thread != NULL ) {
+_Thread_queue_Extract( the_thread );
+  }
 
   _MPCI_Return_packet( the_packet_prefix );
   break;
diff --git a/cpukit/rtems/src/partmp.c b/cpukit/rtems/src/partmp.c
index ac2b48aba4..99af7adf71 100644
--- a/cpukit/rtems/src/partmp.c
+++ b/cpukit/rtems/src/partmp.c
@@ -242,8 +242,9 @@ static void _Partition_MP_Process_packet(
 
   the_thread = _Thread_MP_Find_proxy( the_packet->proxy_id );
 
-  if ( ! _Thread_Is_null( th

Re: Remove implementation-specific inline functions with exactly one caller?

[Joel Sherrill]

On Tue, Oct 13, 2020 at 6:41 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> we have a couple of implementation-specific inline functions defined in
> header files which have exactly one caller. I think we should remove
> these functions in general, to reduce the lines of code, making code
> review easier, and reduce the number of functions which need
> documentation. If it makes the caller site more clear, then we should
> place them in the source file of the caller. Examples:
>
> cpukit/rtems/src/partcreate.c:  the_partition = _Partition_Allocate();
> cpukit/include/rtems/rtems/partimpl.h:RTEMS_INLINE_ROUTINE
> Partition_Control *_Partition_Allocate ( void )
>
> cpukit/include/rtems/rtems/regionimpl.h:RTEMS_INLINE_ROUTINE bool
> _Region_Free_segment (
> cpukit/rtems/src/regionreturnsegment.c:  if ( _Region_Free_segment(
> the_region, segment ) ) {
>
> cpukit/sapi/src/extensiondelete.c:  the_extension = _Extension_Get( id );
> cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE
> Extension_Control *_Extension_Get( Objects_Id id )
>
> cpukit/sapi/src/extensioncreate.c:  the_extension = _Extension_Allocate();
> cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE
> Extension_Control *_Extension_Allocate( void )
>
> cpukit/sapi/src/extensiondelete.c:_Extension_Free( the_extension );
> cpukit/include/rtems/extensionimpl.h:RTEMS_INLINE_ROUTINE void
> _Extension_Free (
>
> What do you think?
>

I think that having a single caller is not by itself a reason to eliminate
a method.

Although it predates C++, the design of RTEMS internal interfaces was based
on strong packaging and encapsulation.

This particular change would expose the allocation scheme for these object
classes to the caller and the need for a cast. Under the original rules,
hiding
that had value.

In this case, it is probably OK because the caller should always be the API
 that actually defined the method  But if the simple, single caller method
is not defined in the same "class" where it is called, that would break the
encapsulation.

We also have to consider if this has a negative impact on readability. In
this
case, that seems unlikely as well since the verb isn't changing and there
is no algorithm or internals exposure. Sometimes, a simple inline is hiding
something that is ugly and makes the callers look better. Certainly this
is hiding a cast. But that's not necessarily inherently ugly.

I'm not giving blanket permission. I'm saying it is worth considering on a
case by case method and updating the coding conventions on inlines.

--joel

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

[PATCH 2/5] shell/shell.c: Fix an implicit type cast

[Frank Kuehndel]

From: Frank Kühndel 

With some compiler warnings enabled, the implicit cast may trigger
a compiler warning. The explicit cast avoids this.
---
 cpukit/libmisc/shell/shell.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index 77214d0be4..c5fc1f5c48 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -620,7 +620,9 @@ static int rtems_shell_line_editor(
 case 21:/* Control-U */
   if (col > 0)
   {
-int clen = strlen (line);
+/* strlen() returns size_t but fprintf("%*...") below requires
+ * int! */
+int clen = (int) strlen (line);
 int bs;
 
 strcpy (line, line + col);
-- 
2.26.2

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

[PATCH 0/5] Fix several warnings and minor issues

[Frank Kuehndel]

From: Frank Kühndel 

This set of small patches fixes a few minor issues such as compiler
warnings, utilization of a wrong constant or bad uses of string copy.

Frank Kühndel (5):
  fsdosfsname01: Fix string truncation warning
  shell/shell.c: Fix an implicit type cast
  shell/shell.c:  Fix illegal string copy
  shell/main_edit.c: Fix use of wrong constant
  shell/main_edit.c: Fix string truncation warning

 cpukit/libmisc/shell/main_edit.c| 13 -
 cpukit/libmisc/shell/shell.c| 22 +-
 testsuites/fstests/fsdosfsname01/init.c | 13 +++--
 3 files changed, 32 insertions(+), 16 deletions(-)

-- 
2.26.2

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

[PATCH 1/5] fsdosfsname01: Fix string truncation warning

[Frank Kuehndel]

From: Frank Kühndel 

This patch fixes a compiler warning:

../../../testsuites/fstests/fsdosfsname01/init.c:430:19: warning:
'%s' directive output may be truncated writing up to 6424 bytes into
a region of size 257 [-Wformat-truncation=]

The buffer 'dirname' is exactly large enough so that no truncation
can ever occur. Using the return value of snprintf() is an official
supported way to suppress the warning.

I considered the comment of Joel Sherrill about not replacing snprintf():
https://lists.rtems.org/pipermail/devel/2020-September/062113.html
---
 testsuites/fstests/fsdosfsname01/init.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/testsuites/fstests/fsdosfsname01/init.c 
b/testsuites/fstests/fsdosfsname01/init.c
index 3689da8eed..a916e392f7 100644
--- a/testsuites/fstests/fsdosfsname01/init.c
+++ b/testsuites/fstests/fsdosfsname01/init.c
@@ -422,14 +422,15 @@ static void test_creating_invalid_directories( void )
   unsigned int index;
   int  rc;
   char dirname[MAX_NAME_LENGTH_INVALID + MOUNT_DIR_SIZE + 1];
-
+  int  len;
 
   for ( index = 0; index < NUMBER_OF_DIRECTORIES_INVALID; ++index ) {
-snprintf( dirname,
-  sizeof( dirname ),
-  "%s/%s",
-  MOUNT_DIR,
-  DIRECTORY_NAMES_INVALID[index] );
+len = snprintf( dirname,
+sizeof( dirname ),
+"%s/%s",
+MOUNT_DIR,
+DIRECTORY_NAMES_INVALID[index] );
+rtems_test_assert( len < sizeof( dirname ) );
 rc = mkdir( dirname, S_IRWXU | S_IRWXG | S_IRWXO );
 rtems_test_assert( rc == -1 );
   }
-- 
2.26.2

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

[PATCH 4/5] shell/main_edit.c: Fix use of wrong constant

[Frank Kuehndel]

From: Frank Kühndel 

realpath() requires a buffer of size PATH_MAX and not of size
FILENAME_MAX according to 'man realpath (3)'.
---
 cpukit/libmisc/shell/main_edit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index e43ff68d2b..02214bd942 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -32,6 +32,7 @@
 //
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -282,7 +283,7 @@ static void delete_editor(struct editor *ed) {
 }
 
 static struct editor *find_editor(struct env *env, char *filename) {
-  char fn[FILENAME_MAX];
+  char fn[PATH_MAX];
   struct editor *ed = env->current;
   struct editor *start = ed;
 
-- 
2.26.2

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

[PATCH 3/5] shell/shell.c: Fix illegal string copy

[Frank Kuehndel]

From: Frank Kühndel 

This is an illegal use of strcpy() because one is not allowed to
use this function with overlapping source and destination buffers;
whereas memmove() is explicitly designed to handle such cases.

The copiler warning was:

../../../cpukit/libmisc/shell/shell.c:626:13: warning:
'strcpy' accessing between 1 and 2147483645 bytes at offsets
0 and [1, 2147483647] may overlap up to 2147483644 bytes at
offset [1, 2147483644] [-Wrestrict]
---
 cpukit/libmisc/shell/shell.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index c5fc1f5c48..1a3b438b37 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -287,6 +287,16 @@ void rtems_shell_dup_current_env(rtems_shell_env_t *copy)
   copy->managed = false;
 }
 
+/*
+ *  Move a string in a buffer to the left (e.g. when a character
+ *  is deleted). The string must be NUL-terminated and the
+ *  NUL-character will be moved too.
+ */
+static void rtems_shell_move_left( char *start, size_t offset )
+{
+  memmove(start, start + offset, strlen(start + offset) + 1);
+}
+
 /*
  *  Get a line of user input with modest features
  */
@@ -393,7 +403,7 @@ static int rtems_shell_line_editor(
   {
 int end;
 int bs;
-strcpy (&line[col], &line[col + 1]);
+rtems_shell_move_left(line + col, 1);
 if (output) {
   fprintf(out,"\r%s%s ", prompt, line);
   end = (int) strlen (line);
@@ -432,7 +442,7 @@ static int rtems_shell_line_editor(
 case 4: /* Control-D */
   if (strlen(line)) {
 if (col < strlen(line)) {
-  strcpy (line + col, line + col + 1);
+  rtems_shell_move_left(line + col, 1);
   if (output) {
 int bs;
 fprintf(out,"%s \b", line + col);
@@ -508,7 +518,7 @@ static int rtems_shell_line_editor(
   {
 int bs;
 col--;
-strcpy (line + col, line + col + 1);
+rtems_shell_move_left(line + col, 1);
 if (output) {
   fprintf(out,"\b%s \b", line + col);
   for (bs = 0; bs < ((int) strlen (line) - col); bs++)
@@ -625,7 +635,7 @@ static int rtems_shell_line_editor(
 int clen = (int) strlen (line);
 int bs;
 
-strcpy (line, line + col);
+rtems_shell_move_left(line, col);
 if (output) {
   fprintf(out,"\r%s%*c", prompt, clen, ' ');
   fprintf(out,"\r%s%s", prompt, line);
-- 
2.26.2

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

[PATCH 5/5] shell/main_edit.c: Fix string truncation warning

[Frank Kuehndel]

From: Frank Kühndel 

Using strlcpy() instead of strncpy():

1) Prevents the compiler warnings
2) Ensures, the string is NUL terminated.
3) Avoids that strncpy() unnecessary fills the unused part of the buffer with
   0 bytes.

(Note that realpath() also returns NULL if the file does not exist - that
happens always if someone creates a new file with the editor of the shell.)
---
 cpukit/libmisc/shell/main_edit.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index 02214bd942..a0110495e8 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -283,11 +283,13 @@ static void delete_editor(struct editor *ed) {
 }
 
 static struct editor *find_editor(struct env *env, char *filename) {
-  char fn[PATH_MAX];
+  char fnbuf[PATH_MAX];
+  char *fn = fnbuf;
   struct editor *ed = env->current;
   struct editor *start = ed;
 
-  if (!realpath(filename, fn)) strncpy(fn, filename, FILENAME_MAX);
+  /* Note: When realpath() == NULL, usually the file doesn't exist */
+  if (!realpath(filename, fn)) { fn = filename; }
 
   do {
 if (strcmp(fn, ed->filename) == 0) return ed;
@@ -298,7 +300,7 @@ static struct editor *find_editor(struct env *env, char 
*filename) {
 
 static int new_file(struct editor *ed, char *filename) {
   if (*filename) {
-strncpy(ed->filename, filename, FILENAME_MAX);
+strlcpy(ed->filename, filename, sizeof(ed->filename));
   } else {
 sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
 ed->newfile = 1;
@@ -1776,8 +1778,8 @@ static void save_editor(struct editor *ed) {
 return;
   }
 }
-strncpy(
-  ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
+strlcpy(
+  ed->filename, (const char*) ed->env->linebuf, sizeof(ed->filename));
 ed->newfile = 0;
   }
 
-- 
2.26.2

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

Re: Build fail on debian - Toolset build error

[Joel Sherrill]

On Mon, Oct 12, 2020 at 11:38 PM Chris Johns  wrote:

> On 13/10/20 1:06 am, Karel Gardas wrote:
> > On 10/12/20 3:50 PM, Anders Montonen wrote:
> >> Hi,
> >>
> >>> On 12 Oct 2020, at 15:30, Karel Gardas  >>> > wrote:
> >>>
> >>>
> >>> Sure, but you have to install header files whatever this means on
> >>> macosx. On Ubuntu this means 'apt install python2.7-dev’
> >>
> >> System frameworks on macOs usually include the development libraries and
> >> headers. Running “python-config —cflags”, and “python-config
> >> —ldflags” returns the compiler and linker flags needed.
> >
> > Check where is Python.h -- if it's available, then probably gdb's
> > configure is not able to pick it up -- probably due to missing
> > parameters -- which should be supplied by rsb. Anyway, you (or OP) are
> > on macosx which is not that usual so you will probably need to do some
> > tweaks. If it's not available, you need to convince your python install
> > to install all headers and libs.
> >
> > Also, have a look into rtems-source-builder/source-builder/sb -- not
> > sure, but there is no macosx.py there but perhaps it should be... (like
> > linux, openbsd, netbsd etc. are there too...)
>
> The detection is here:
>
>
> https://git.rtems.org/rtems-source-builder/tree/source-builder/config/gdb-common-1.cfg#n7
>
> Updates welcome. The detection support is a continuous work in progress so
> if
> something is needed to help a specific case please add it. The config
> looks for
> a suitable python to use, then for the config command and then the
> settings it has.
>

As mentioned on various Linux distributions, you have to install a
python2-devel
package. The gdb check is here:

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/configure.ac;h=6b4b0fa85109d1e0d0a1610fece2ce13295befb9;hb=HEAD#l674

This has been a common issue long enough that Chris moved gdb to one of the
first things built so the error would stop a build near the beginning
rather than after
building gcc.

In a perfect world, sb-check would know how to check for the libraries
needed
which is mostly python2-devel and zlib-devel.


> Andrew, I do not test building with macports or homebrew. The amount of
> work
> that would generate for me would be enough to consume all my time.
>

Same for alternative Linux distributions and other BSD variants. There are
just
too many for the core developers to include in their testing. This is where
the
community has to step up if someone cares.

I develop on CentOS but test on CentOS, Ubuntu, and FreeBSD. I try
to visit Windows (Cygwin and MinGW on occasion. Other core developers
have their test OS set. In total, we cover a pretty wide swath but there
are so many we don't hit. But none of us test on Mint or NetBSD and
AFAIK there are not regular reports from Debian.even though Ubuntu should
be close.

I should end by saying that if a host is important, there are the options of
testing it yourself or supporting a core developer add it to their set. It
just
takes time and resources to test a host.

My recent BSP build sweeps have taken 42-48 hours on an 8-core Xeon.
My regular check of build all tools, run bsp tester, and then build bsps and
test on simulators takes from 20 to ~48 hours depending on the computer.
Nice weekend job for someone's computer if you can't decicate a computer
to the task.

--joel

>
> Chris
> ___
> 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: aarch64/a53_ilp32_qemu: implicit declaration of function 'truncl'

[Kinsey Moore]

On Sat, Oct 10, 2020 at 8:13 AM Sebastian Huber 
mailto:sebastian.hu...@embedded-brains.de>> 
wrote:
On 10/10/2020 15:11, Sebastian Huber wrote:

> Hello Kinsey,
>
> the new aarch64/a53_ilp32_qemu produces a lot of warnings like this:
>
> ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning:
> implicit declaration of function 'truncl'
> [-Wimplicit-function-declaration]
> ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: warning:
> incompatible implicit declaration of built-in function 'truncl'
>
> Is this a known issue?

It is likely that this is because some/many architectures do not
have long double support in newlib. Or have a true long double
type. This will require a newlib discussion.


There is also this warning:

cpukit/libmisc/stackchk/check.c:455:5: warning: cast to pointer from
integer of different size [-Wint-to-pointer-cast]

This is probably an error. Could you please fix the warnings specific to
the new BSPs.

This looks like code being sloppy that isn't the fault of this BSP. It is
just one where sizeof(int) != sizeof(void *).

Kinsey.. likely solution is to replace the cast/type with intptr_t or uintptr_t.

[]
Sorry, I didn’t see these when I was developing. I’ll work up some patches for 
them.

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

Re: [PATCH v2] rtems: Generate

[Gedare Bloom]

On Sun, Oct 11, 2020 at 4:31 PM Chris Johns  wrote:
>
> On 12/10/20 1:16 am, Sebastian Huber wrote:
> > On 08/10/2020 08:18, Sebastian Huber wrote:
> >
> >> On 07/10/2020 21:12, Gedare Bloom wrote:
> >>
> >>> On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber
> >>>  wrote:
>  On 07/10/2020 17:26, Gedare Bloom wrote:
> 
> > Thinking about the discussion about ordering directives in the docs,
> > the generated header reorders directives also. Is it also doing
> > generation by alphabetical order?
> >
> > Should we consider using the same order as defined for the API
> > documentation? I guess this would make the Doxygen consistently
> > ordered wrt the docs.
>  This would make things a lot more complicated. For the Doxygen we have
>  to take also the C language into account. For example before you use a
>  type, it must be declared. This is done through automatic dependency
>  tracking and a topological sorting. Adding a manual order into this
>  stuff would be difficult.
> >>> Yeah, maybe. The value of ordering in the headers and doxygen is
> >>> probably less than in a manual. We can revisit later if we like. It
> >>> shouldn't be too hard in an API header (as opposed to an
> >>> implementation header with inlines) to group first the typedefs and
> >>> then the function declarations. But I have no real concern about the
> >>> ordering here, it was just a thought.
> >>
> >> Good, I added a ticket for this:
> >>
> >> https://devel.rtems.org/ticket/4134#ticket
> >>
> >> It is not on my high priority list.
> >
> > It turned out to be pretty easy to fix with a bubble sort:
> >
> > https://git.rtems.org/rtems-central/commit/?id=3f3e088740abc2d00cf9986452bef81eae83260e
>
>
> Nice. The contextlib has changed since python 2, the redirect looks 
> interesting.
>
> > Generated :
> >
> > https://git.rtems.org/rtems/tree/cpukit/include/rtems/io.h
>
This is much more readable. Thank you for figuring this out!

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

Re: Need help debugging sp16.exe

[Gedare Bloom]

On Mon, Oct 12, 2020 at 11:19 AM Joel Sherrill  wrote:
>
>
>
> On Mon, Oct 12, 2020 at 10:47 AM Richi Dubey  wrote:
>>>
>>> There are existing checks scattered throughout the source. Do any need to 
>>> be in your scheduler?
>>
>> I don't understand. If there are already checks scattered through, why do I 
>> need more checks in my scheduler? Are these checks independent from the 
>> checks I might need in the scheduler? Please explain.
>
>
> Your scheduler is a unique piece of software. It may be making assumptions 
> that are not checked in the generic scheduler code. And checks in other 
> schedulers are of no use to you.
>
> There may not be any but this is something to consider.
>
>>
>>
>>> + Looks like the bsp has fast idle on but that should not impact anything.
>>
>> What's fast idle? I found this. :p How can time run as fast as possible?
>
>
> Simulators tend to run slowly. They also may spend a long time when testing 
> RTEMS executing the idle thread waiting for time to pass. Fast idle just says 
> if a clock tick occurs while the idle thread is running, call clock tick over 
> and over until another thread is unblocked and preempts idle.
>>
>>
>>> + Run this with the another scheduler and see if you can identify when that 
>>> scheduler makes the decision you are missing. There has to be one of the 
>>> scheduler hooks that is making a different decision. Run the test side by 
>>> side with two different schedulers. Alternate forward motion in the two and 
>>> compare the behaviour.
>>
>> This is genius. Thanks a lot. I'm gonna work on this.
>>
>>> + Adding trading might help but is probably more trouble to set up than 
>>> just comparing good and bad schedulers in parallel.
>>
>> What's trading?
>
>
> That's a bad typo or auto-correct. Probably should have been tactic.
tracing

>>
>>
>>> + Look at what every failing test is doing. May be a common issue and one 
>>> is easier to debug
>>
>> Thanks. I'll check this.
>
>
> Looking across all failing tests usually helps. For some reason, one tends to 
> be easier to debug than the others.
>
> Also some of the tests have a lot of code up front that doesn't impact what 
> you are testing. It may be possible to disable early parts of sp16 to reduce 
> what you have to step through and compare schedulers.
>
> --joel
>>
>>
>>
>> On Sun, Oct 11, 2020 at 5:08 AM Joel Sherrill  wrote:
>>>
>>>
>>>
>>> On Sat, Oct 10, 2020, 10:47 AM Richi Dubey  wrote:

 Hi Mr. Huber,

 Thanks for checking in.

> I suggested to enable your new scheduler implementation as the default
> to check if it is in line with the standard schedulers. I would first
> get some high level data. Select a BSP with good test results on a
> simulator (for example sparc/leon3 or arm/realview_pbx_a9_qemu). Run the
> tests and record the test data. Then enable the SMP EDF scheduler as the
> default, run the tests, record the data. Then enable your scheduler as
> the default, run the tests, record the data. Then get all tests which
> fail only with your scheduler.

 Yes, this is something I've already done based on your previous 
 suggestion. I set SCHEDULER_STRONG_APA(the current RTEMS master's version) 
 as the default scheduler for both sp and SMP and ran the test (on both 
 sparc/leon3 and arm/realview_pbx_a9_qemu). Then I set 
 SCHEDULER_STRONG_APA(my version) as the default scheduler for both sp and 
 SMP and ran the test and compared it with the master's strong apa result. 
 The following (extra) tests failed:

  sp02.exe
  sp16.exe
  sp30.exe
  sp31.exe
  sp37.exe
  sp42.exe
  spfatal29.exe
  tm24.exe

> Do a high level analysis of all failing
>
> tests. Try to figure out a new scenario for the test smpstrongapa01.

 Okay, I would look into this. This is a great suggestion, thanks!


> Do all the development with RTEMS_DEBUG enabled!
> Add _Assert() stuff to your scheduler. Check pre- and post-conditions of
> all operations. Check invariants.

 How do I check postconditions? Using _Assert() or by manually debugging 
 each function call?
>>>
>>>
>>> There are existing checks scattered throughout the source. Do any need to 
>>> be in your scheduler?
>>>
>>> Random thoughts:
>>>
>>> + Looks like the bsp has fast idle on but that should not impact anything.
>>>
>>> + Run this with the another scheduler and see if you can identify when that 
>>> scheduler makes the decision you are missing. There has to be one of the 
>>> scheduler hooks that is making a different decision. Run the test side by 
>>> side with two different schedulers. Alternate forward motion in the two and 
>>> compare the behaviour.
>>>
>>> + Adding trading might help but is probably more trouble to set up than 
>>> just comparing good and bad schedulers in parallel.
>>>
>>> + Look at what every failing test is doing. May be a common issue and one 
>>

Re: On Master All GDB Builds Fail on Cygwin

[Joel Sherrill]

Finally got an answer from Corinna and she said to report this to gdb. But
when I went to repeat it, it builds now.

Unfortunately, the source builder ended with this on Cygwin. A Linux VM on
the same physical computer doesn't have trouble sending to build@. I do
have a VPN up which is not always on.

Build Sizes: usage: 4.963GB total: 1.691GB (sources: 397.768MB, patches:
20.153KB, installed 1.302GB)
Mailing report: bu...@rtems.org
Mail Send Failure: error: sending mail: [Errno 111] Connection refused
Build Set: Time 1:49:57.656442

Any ideas? Nothing else is in the log.

What's the best way to send test mail from Cygwin?

Thanks.

--joel

On Mon, Sep 28, 2020 at 8:37 PM Chris Johns  wrote:

> On 29/9/20 5:35 am, Joel Sherrill wrote:
> > Hi
> >
> > I left a build going yesterday on Cygwin and GDB failed with this for
> every
> > architecture. I updated my Cygwin install this morning and it still
> fails with this:
> >
> >
> cp-support.o:/home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/arm-rtems6-gdb-0295dde-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-0295dde/gdb/psymtab.h:32:(.text+0x5291):
> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS
> init
> > function for thread_local_segv_handler'
> >
> cp-support.o:/home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/arm-rtems6-gdb-0295dde-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-0295dde/gdb/psymtab.h:32:(.text+0x529b):
> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS
> init
> > function for thread_local_segv_handler'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [Makefile:1867: gdb.exe] Error 1
> > make[2]: Leaving directory
> >
> '/home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/arm-rtems6-gdb-0295dde-x86_64-pc-cygwin-1/build/gdb'
> >
> > I found that there are others with the same problem. The only one with a
> patch
> > was this:
> >
> >
> https://stackoverflow.com/questions/61984974/failed-to-build-avr-and-arm-gdb-9-1-under-cygwin-relocation-truncated-to-fit
> >
> > I know Cygwin is way down folks' list but any ideas?
>
> It is best to raise this with gdb and/or cygwin.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Sentinel-6 and RTEMS??

[Joel Sherrill]

Hi

I noticed this is scheduled to launch Nov 10. Per the ESA mission
description and the organizations involved, I expect there is at least one
RTEMS-based instrument or subsystem in it.

https://sentinel.esa.int/web/sentinel/missions/sentinel-6/mission-summary

The Star Tracker has no provider and that's a possible RTEMS system. I know
of two star trackers that run RTEMS.

Does anyone know anything about this mission?

Thanks

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

Re: On Master All GDB Builds Fail on Cygwin

[Chris Johns]

On 14/10/20 9:42 am, Joel Sherrill wrote:
> Finally got an answer from Corinna and she said to report this to gdb. But 
> when
> I went to repeat it, it builds now.

Weird. Was Cygwin updated?

> Unfortunately, the source builder ended with this on Cygwin. A Linux VM on the
> same physical computer doesn't have trouble sending to build@. I do have a VPN
> up which is not always on. 
> 
> Build Sizes: usage: 4.963GB total: 1.691GB (sources: 397.768MB, patches:
> 20.153KB, installed 1.302GB)
> Mailing report: bu...@rtems.org 
> Mail Send Failure: error: sending mail: [Errno 111] Connection refused
> Build Set: Time 1:49:57.656442
> 
> Any ideas? Nothing else is in the log.

Firewall?

> What's the best way to send test mail from Cygwin? 

This should work. I suspect it is something local to you.

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

Re: On Master All GDB Builds Fail on Cygwin

[Joel Sherrill]

On Tue, Oct 13, 2020, 6:37 PM Chris Johns  wrote:

> On 14/10/20 9:42 am, Joel Sherrill wrote:
> > Finally got an answer from Corinna and she said to report this to gdb.
> But when
> > I went to repeat it, it builds now.
>
> Weird. Was Cygwin updated?
>

No. Sebastian bumped the head of gdb.

>
> > Unfortunately, the source builder ended with this on Cygwin. A Linux VM
> on the
> > same physical computer doesn't have trouble sending to build@. I do
> have a VPN
> > up which is not always on.
> >
> > Build Sizes: usage: 4.963GB total: 1.691GB (sources: 397.768MB, patches:
> > 20.153KB, installed 1.302GB)
> > Mailing report: bu...@rtems.org 
> > Mail Send Failure: error: sending mail: [Errno 111] Connection refused
> > Build Set: Time 1:49:57.656442
> >
> > Any ideas? Nothing else is in the log.
>
> Firewall?
>
> > What's the best way to send test mail from Cygwin?
>
> This should work. I suspect it is something local to you.
>

Weird it would just impact Cygwin and not the VM. I didn't have mail or
mailx installed to test with. Is there a direct Python way to try with the
tools?

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

Re: On Master All GDB Builds Fail on Cygwin

[Sebastian Huber]

On 14/10/2020 02:45, Joel Sherrill wrote:

On Tue, Oct 13, 2020, 6:37 PM Chris Johns > wrote:


On 14/10/20 9:42 am, Joel Sherrill wrote:
> Finally got an answer from Corinna and she said to report this
to gdb. But when
> I went to repeat it, it builds now.

Weird. Was Cygwin updated?


No. Sebastian bumped the head of gdb.


Yes, the update fixes a GDB build issue on Debian:

commit de38d64ad2502312afbac806474c1e2c0fe5
Author: Pedro Alves 
Date:   Tue Sep 29 20:08:51 2020 +0100

    Tweak gdbsupport/valid-expr.h for GCC 6, fix build

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

Re: On Master All GDB Builds Fail on Cygwin

[Chris Johns]

On 14/10/20 11:45 am, Joel Sherrill wrote:
> On Tue, Oct 13, 2020, 6:37 PM Chris Johns  > wrote:
> 
> On 14/10/20 9:42 am, Joel Sherrill wrote:
> > Finally got an answer from Corinna and she said to report this to gdb. 
> But
> when
> > I went to repeat it, it builds now.
> 
> Weird. Was Cygwin updated?
> 
> No. Sebastian bumped the head of gdb.

Ah OK.

> > Unfortunately, the source builder ended with this on Cygwin. A Linux VM 
> on the
> > same physical computer doesn't have trouble sending to build@. I do 
> have a VPN
> > up which is not always on. 
> >
> > Build Sizes: usage: 4.963GB total: 1.691GB (sources: 397.768MB, patches:
> > 20.153KB, installed 1.302GB)
> > Mailing report: bu...@rtems.org 
> >
> > Mail Send Failure: error: sending mail: [Errno 111] Connection refused
> > Build Set: Time 1:49:57.656442
> >
> > Any ideas? Nothing else is in the log.
> 
> Firewall?
> 
> > What's the best way to send test mail from Cygwin?
> 
> This should work. I suspect it is something local to you.
> 
> 
> Weird it would just impact Cygwin and not the VM. I didn't have mail or mailx
> installed to test with. Is there a direct Python way to try with the tools?

Could you telnet to the port to see if you are being blocked?

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