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.
-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.hu...@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@rtems.org >>> http://www.rtems.org/mailman/listinfo/rtems-devel >> _______________________________________________ >> rtems-devel mailing list >> rtems-devel@rtems.org >> http://www.rtems.org/mailman/listinfo/rtems-devel > > -- > Joel Sherrill, Ph.D. Director of Research & Development > joel.sherr...@oarcorp.com On-Line Applications Research > Ask me about RTEMS: a free RTOS Huntsville AL 35805 > Support Available (256) 722-9985 > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
