Re: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-17 Thread Sebastian Huber 

On 13/01/17 15:54, Joel Sherrill wrote:



On Fri, Jan 13, 2017 at 4:47 AM, Sebastian Huber 
> wrote:


On 13/01/17 09:48, Sebastian Huber wrote:

On 12/01/17 22:44, Joel Sherrill wrote:

I repeat that I would like to purge old tests that result
in conditionals in
source code we no longer need. So any HAVE_XXX that are a side
effect of transitioning newlib additions should be removed.


I removed three tests today which I added in the last two
years or so.


I removed a couple of more obsolete configure stuff. I am done for
now.


Thanks. It is a continuous battle of creep and push back.

Without looking, I am sure you are right that 
__RTEMS_DO_NOT_INLINE_THREAD_ENABLE_DISPATCH__
is no longer used but it did serve a purpose that may have been lost 
in all the

rework.

When doing coverage testing, inlining a method with one of more 
conditionals
increases the cyclomatic complexity of the calling method and number 
of test
cases required to do full coverage of all branch paths. That flag 
eliminated

at least 250 paths to test in the generated code.

With the rework, did anything get inlined lots of times that includes a
conditional test? If so, then the calling method has hidden cyclomatic
complexity and requires increased test cases for full coverage.

I am pretty sure this is written down as advice in the coverage area
but I have no idea how to turn it into good solid coding style/rules.
The best I can formulate is:

Inlining a method requires that it be fully tested in the context of each
place it is called. Inlining complex methods with conditionals is 
undesirable

from a coverage testing viewpoint. Try to inline only simple methods.


Yes, this is something to think about. The thread dispatch 
disable/enable is used in fewer places now, maybe it makes sense to make 
it a non-inline function to simplify things or replace it with 
_Thread_Dispatch_direct() if possible.


--
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: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-13 Thread Joel Sherrill 
On Fri, Jan 13, 2017 at 4:47 AM, Sebastian Huber  wrote:

> On 13/01/17 09:48, Sebastian Huber wrote:
>
>> On 12/01/17 22:44, Joel Sherrill wrote:
>>
>>> I repeat that I would like to purge old tests that result in
>>> conditionals in
>>> source code we no longer need. So any HAVE_XXX that are a side
>>> effect of transitioning newlib additions should be removed.
>>>
>>
>> I removed three tests today which I added in the last two years or so.
>>
>
> I removed a couple of more obsolete configure stuff. I am done for now.
>
>
Thanks. It is a continuous battle of creep and push back.

Without looking, I am sure you are right that __RTEMS_DO_NOT_
INLINE_THREAD_ENABLE_DISPATCH__
is no longer used but it did serve a purpose that may have been lost in all
the
rework.

When doing coverage testing, inlining a method with one of more conditionals
increases the cyclomatic complexity of the calling method and number of test
cases required to do full coverage of all branch paths. That flag eliminated
at least 250 paths to test in the generated code.

With the rework, did anything get inlined lots of times that includes a
conditional test? If so, then the calling method has hidden cyclomatic
complexity and requires increased test cases for full coverage.

I am pretty sure this is written down as advice in the coverage area
but I have no idea how to turn it into good solid coding style/rules.
The best I can formulate is:

Inlining a method requires that it be fully tested in the context of each
place it is called. Inlining complex methods with conditionals is
undesirable
from a coverage testing viewpoint. Try to inline only simple methods.

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

Re: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-13 Thread Sebastian Huber 

On 13/01/17 09:48, Sebastian Huber wrote:

On 12/01/17 22:44, Joel Sherrill wrote:
I repeat that I would like to purge old tests that result in 
conditionals in

source code we no longer need. So any HAVE_XXX that are a side
effect of transitioning newlib additions should be removed.


I removed three tests today which I added in the last two years or so. 


I removed a couple of more obsolete configure stuff. I am done for now.

--
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: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-13 Thread Sebastian Huber 

On 12/01/17 22:44, Joel Sherrill wrote:
I repeat that I would like to purge old tests that result in 
conditionals in

source code we no longer need. So any HAVE_XXX that are a side
effect of transitioning newlib additions should be removed.


I removed three tests today which I added in the last two years or so.

--
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: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-12 Thread Sebastian Huber 



On 13/01/17 04:52, Chris Johns wrote:

On 13/01/2017 08:44, Joel Sherrill wrote:



On Thu, Jan 12, 2017 at 3:34 PM, Chris Johns > wrote:

On 13/01/2017 00:37, Joel Sherrill wrote:

I am OK with this and think it will give a more helpful message.


I am OK with the change however I would like the patch to wait until
docs.rtems.org  is up and a permanent link
can be used for 


+1 for permanent URLs for a number of things. :)



How does https://docs.rtems.org/branches/master/rsb/quick-start.html 
look ? :)


Great, that is what I was looking for. Very nice.

--
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: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-12 Thread Chris Johns 

On 13/01/2017 08:44, Joel Sherrill wrote:



On Thu, Jan 12, 2017 at 3:34 PM, Chris Johns > wrote:

On 13/01/2017 00:37, Joel Sherrill wrote:

I am OK with this and think it will give a more helpful message.


I am OK with the change however I would like the patch to wait until
docs.rtems.org  is up and a permanent link
can be used for 


+1 for permanent URLs for a number of things. :)



How does https://docs.rtems.org/branches/master/rsb/quick-start.html 
look ? :)


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

Re: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-12 Thread Joel Sherrill 
On Thu, Jan 12, 2017 at 3:34 PM, Chris Johns  wrote:

> On 13/01/2017 00:37, Joel Sherrill wrote:
>
>> I am OK with this and think it will give a more helpful message.
>>
>
> I am OK with the change however I would like the patch to wait until
> docs.rtems.org is up and a permanent link can be used for 
>
>
+1 for permanent URLs for a number of things. :)

I repeat that I would like to purge old tests that result in conditionals in
source code we no longer need. So any HAVE_XXX that are a side
effect of transitioning newlib additions should be removed.

--joel


> +AC_DEFUN([RTEMS_TOOL_CHAIN_ERROR],AC_MSG_ERROR([please update your
>> tool chain via the RSB
>> (https://devel.rtems.org/wiki/Developer/Tools/RSB)]
>> ))
>> +
>>
>
> 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: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-12 Thread Chris Johns 

On 13/01/2017 00:37, Joel Sherrill wrote:

I am OK with this and think it will give a more helpful message.


I am OK with the change however I would like the patch to wait until 
docs.rtems.org is up and a permanent link can be used for 



+AC_DEFUN([RTEMS_TOOL_CHAIN_ERROR],AC_MSG_ERROR([please update your
tool chain via the RSB
(https://devel.rtems.org/wiki/Developer/Tools/RSB)]
))
+


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

Re: [PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

2017-01-12 Thread Joel Sherrill 
I am OK with this and think it will give a more helpful message.

Did you notice any other grossly out of date, unneeded tests
that generated conditionals for the code?

We have been very nice about not hard forcing people to update
and things like the sys/cpuset.h tests should just be removed now
that your toolset would have to be over a year old.

--joel

On Thu, Jan 12, 2017 at 3:01 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Stop the build with a common error message in case the tool chain is
> seriously out of date.
> ---
>  cpukit/configure.ac | 27 +--
>  1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/cpukit/configure.ac b/cpukit/configure.ac
> index 4410bf1..4aad929 100644
> --- a/cpukit/configure.ac
> +++ b/cpukit/configure.ac
> @@ -23,6 +23,8 @@ RTEMS_ENABLE_DRVMGR
>  RTEMS_ENV_RTEMSCPU
>  RTEMS_CHECK_RTEMS_DEBUG
>
> +AC_DEFUN([RTEMS_TOOL_CHAIN_ERROR],AC_MSG_ERROR([please update your tool
> chain via the RSB (https://devel.rtems.org/wiki/Developer/Tools/RSB)]))
> +
>  # Is this a supported CPU?
>  AC_MSG_CHECKING([if cpu $RTEMS_CPU is supported])
>  if test -d "$srcdir/score/cpu/$RTEMS_CPU"; then
> @@ -57,9 +59,7 @@ AC_CHECK_FUNCS([creat \
>sleep \
>telldir \
>usleep],,
> -  [rtems_missing_func="$ac_func";break])
> -AS_IF([test -n "$rtems_missing_func"],
> -  AC_MSG_ERROR([Missing function $rtems_missing_func in libc])])
> +  [RTEMS_TOOL_CHAIN_ERROR])
>  AC_CHECK_FUNCS([__assert])
>  AC_CHECK_FUNCS([execl execlp execle execv execvp execve])
>  AC_CHECK_FUNCS([regcomp regexec regerror regfree])
> @@ -75,10 +75,11 @@ AC_CHECK_DECLS([__env_lock],,,[#include ])
>  AC_CHECK_DECLS([__env_unlock],,,[#include ])
>  AC_CHECK_TYPES([struct _Thread_queue_Queue],[],[],[#include
> ])
>  AC_CHECK_SIZEOF([pthread_spinlock_t],[],[],[#include ])
> +AC_CHECK_MEMBER([struct _Thread_queue_Queue._name],[],
> [RTEMS_TOOL_CHAIN_ERROR],[#include ])
>
>  # Mandated by POSIX, older newlibs bogusly provided
> CLOCK_PROCESS_CPUTIME+CLOCK_THREAD_CPUTIME
> -AC_CHECK_DECL([CLOCK_PROCESS_CPUTIME_ID],[],[AC_MSG_ERROR([missing
> define CLOCK_PROCESS_CPUTIME_ID])],[#include ])
> -AC_CHECK_DECL([CLOCK_THREAD_CPUTIME_ID],[],[AC_MSG_ERROR([missing define
> CLOCK_THREAD_CPUTIME_ID])],[#include ])
> +AC_CHECK_DECL([CLOCK_PROCESS_CPUTIME_ID],[],[RTEMS_TOOL_CHAIN_ERROR],[#include
> ])
> +AC_CHECK_DECL([CLOCK_THREAD_CPUTIME_ID],[],[RTEMS_TOOL_CHAIN_ERROR],[#include
> ])
>
>  # Mandated by POSIX, decls not present in some versions of newlib,
>  # some versions stubbed in newlib's rtems crt0
> @@ -136,9 +137,7 @@ AC_CHECK_FUNCS([ttyname getcwd])
>  # Check if the installed toolchain provides these headers
>  # and error out if not.
>  AC_CHECK_HEADERS([tar.h errno.h sched.h sys/cdefs.h sys/queue.h],,
> -  [rtems_missing_header="$ac_header";break])
> -AS_IF([test -n "$rtems_missing_header"],
> -  AC_MSG_ERROR([Missing required header $rtems_missing_header])])
> +  [RTEMS_TOOL_CHAIN_ERROR])
>
>  AC_CHECK_HEADERS([semaphore.h])
>  AM_CONDITIONAL([HAVE_SEMAPHORE_H],[test x"$ac_cv_header_semaphore_h" =
> x"yes"])
> @@ -148,15 +147,15 @@ AM_CONDITIONAL([HAVE_THREADS_H],[test
> x"$ac_cv_header_threads_h" = x"yes"])
>
>  ## error out if libc doesn't provide stdint.h
>  AS_IF([test x"${ac_cv_header_stdint_h}" != xyes],
> -[AC_MSG_ERROR([Required header stdint.h not found])])
> +[RTEMS_TOOL_CHAIN_ERROR])
>
>  ## error out if libc doesn't provide inttypes.h
>  AS_IF([test x"${ac_cv_header_inttypes_h}" != xyes],
> -[AC_MSG_ERROR([Required header inttypes.h not found])])
> +[RTEMS_TOOL_CHAIN_ERROR])
>
>  AC_HEADER_STDBOOL
>  AS_IF([test x"${ac_cv_header_stdbool_h}" != xyes],
> -[AC_MSG_ERROR([No sufficient stdbool.h found])])
> +[RTEMS_TOOL_CHAIN_ERROR])
>
>  AC_CHECK_TYPES([ uint8_t,  int8_t])
>  AC_CHECK_TYPES([uint16_t, int16_t])
> @@ -175,7 +174,7 @@ AC_CHECK_HEADER([pthread.h],[
>AC_CHECK_TYPES([pthread_rwlock_t])
>AC_CHECK_TYPES([pthread_barrier_t])
>AC_CHECK_TYPES([pthread_spinlock_t])
> -  AC_CHECK_TYPES([struct _pthread_cleanup_context],[],[AC_MSG_ERROR([struct
> _pthread_cleanup_context in  is mandatory])],[#include
> ])
> +  AC_CHECK_TYPES([struct _pthread_cleanup_context],[],[
> RTEMS_TOOL_CHAIN_ERROR],[#include ])
>  ])
>
>  AC_CHECK_HEADER([signal.h],[
> @@ -183,7 +182,7 @@ AC_CHECK_HEADER([signal.h],[
>  ])
>
>  if test x"$RTEMS_USE_NEWLIB" = xyes ; then
> -  AC_CHECK_DECLS([__getreent],[],[AC_MSG_ERROR([__getreent() in
>  is mandatory])],[#include ])
> +  AC_CHECK_DECLS([__getreent],[],[RTEMS_TOOL_CHAIN_ERROR],[#include
> ])
>  fi
>
>  RTEMS_CHECK_MULTIPROCESSING
> @@ -191,7 +190,7 @@ RTEMS_CHECK_POSIX_API
>  RTEMS_CHECK_NETWORKING
>  RTEMS_CHECK_SMP
>  if test "${RTEMS_HAS_SMP}" = "yes"; then
> -  AC_CHECK_HEADERS([stdatomic.h],[],[AC_MSG_ERROR([ is
> required for SMP support])])
> +  AC_CHECK_HEADERS([stdatomic.h],[],[RTEMS_TOOL_CHAIN_ERROR])
>  fi
>
>  rtems_major=`echo _RTEMS_VERSION | sed "s/\..*//"`
> --
> 1.8.4.5
>
>