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

Wed May 28 18:49:07 UTC 2014

On 5/28/2014 10:22 AM, Gedare Bloom wrote:
> 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.
I can't turn off the no return warning via the command line. That
touches basedefs.h.

So basedefs.h and assert.h are the reduced set of files touched.

New version attached.
> -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
>>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Minor-conditionals-to-enable-building-Scheduler-Simu.patch
Type: text/x-patch
Size: 2716 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140528/44cd0df3/attachment-0001.bin>