[PATCH] configure: Add RTEMS_TOOL_CHAIN_ERROR

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Jan 17 10:02:09 UTC 2017


On 13/01/17 15:54, Joel Sherrill wrote:
>
>
> On Fri, Jan 13, 2017 at 4:47 AM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> 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.huber at embedded-brains.de
PGP     : Public key available on request.

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




More information about the devel mailing list