On Wed, May 28, 2014 at 2:49 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: > > On 5/28/2014 10:22 AM, Gedare Bloom wrote: >> On Wed, May 28, 2014 at 11:05 AM, Joel Sherrill >> <joel.sherr...@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.hu...@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. You changed to using #if instead of #if defined. I think you want it with the ifdef.
-Gedare _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel