[PATCH 1/4] Minor conditionals to enable building Scheduler Simulator on GNU/Linux

[Joel Sherrill]

On 5/28/2014 7:39 AM, Gedare Bloom wrote:
> On Wed, May 28, 2014 at 5:00 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>> On 2014-05-28 00:16, Joel Sherrill wrote:
>>> - rtems/score/threadimpl.h: _Thread_Start_multitasking does return
>>>    on Scheduler Simulator. Initializing RTEMS returns to the command
>>>    interpreter.
>>>
>>> - rtems/score/smpimpl.h: _SMP_Start_multitasking_on_secondary_processor()
>>>    is not applicable on the Scheduler Simulator and the no return
>>> attribute
>>>    gives a warning.
>>>
>>> - rtems/score/assert.h: Scheduler Simulator uses glibc assert.h on
>>> GNU/Linux.
>>>    This will likely need to be adjusted more for other host compilers and
>>>    C libraries
>>>
>>> - threadrestart.c: Disable assert on Scheduler Simulator. Restarting self
>>>    returns to the command interpreter.
>>
>> I would define RTEMS_COMPILER_NO_RETURN_ATTRIBUTE and _Assert() to nothing
>> in case RTEMS_SCHEDSIM is defined.  Do you really need this debugging stuff
>> for the scheduler simulator?  I don't think we should propagate oddities of
>> the scheduler simulator throughout the code base.
>>
> Yes, this was my initial reaction as well. Probably at least you could
> make Assert_Not_reached() a nop, or write a wrapper for assert that
> depends on schedsim. Can schedsim work more like a real target for
> this case of not returning? I guess usually the system ends up in a
> fatal or halt state? Maybe you can interpose on that state to return
> to the command interpreter.
Schedsim does not really context switch so the paths that assume a task
switches
out and never returns are reachable paths. It is logically a single
thread of control
with the underlying RTEMS code thinking that a thread is "executing" on
the various
cores. When a thread blocks, control returns to the script with a new
executing
thread. In an SMP configuration, the scripts can also change CPU focus
and execute
commands in the context of  the executing thread on that core.

I can live with disabling the noreturn checks and turning off that
warning. I think
that will eliminate the first two of the four spots touched above.

But I don't want to disable the asserts. Right now, we can run with
--enable-rtems-debug
and not get any asserts. The consistency checks are really handy and
they found
bugs in the Affinity Scheduler. So I really do not want to disable
them.  So killing
assertions is undesirable.

I could try to move all of the alternative assert logic under an
RTEMS_SCHEDSIM.
That would make it clearer what it is for and harder to trip.

For know, making Assert_Not_reached() nothing on Schedsim would be
acceptable
for the _Thread_Restart() assertion.

I think this would restrict the patch to the rtems assert.h. Is that
acceptable?

FWIW I have been using the native gcov to get coverage reports on the
various schedulers.
For the parts of RTEMS that are in the scheduler simulator, the coverage
is actually
pretty high without focusing on more than schedulers. And the affinity
scheduler
is the only one I have paid attention to coverage on. The Affinity
scheduler reports
near 100% and the two places not reported as covered can be broken on in
gdb. I
can't explain the discrepancy.  Overall, we are getting 65.78% coverage
of 191 files
(4 schedsim specific included).

> -Gedare
>
>> --
>> 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.
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985