On Wed, May 28, 2014 at 5:00 AM, Sebastian Huber <[email protected]> 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.
-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 : [email protected] > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______________________________________________ > rtems-devel mailing list > [email protected] > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
