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