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

[Gedare Bloom]

On Wed, May 28, 2014 at 11:05 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
> 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?
>
Yes, that would be better.

-Gedare

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