<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 1, 2016 at 12:09 PM, Travis Wheatley <span dir="ltr"><<a href="mailto:travis.wheatley@emergentspace.com" target="_blank">travis.wheatley@emergentspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Working through my first RTEMS debug effort. I am executing the hello sample from the 4.12 tree on a PowerPC target. I am getting a kernel panic that appears to happen in a while loop in rtems_initialize_executive() that invokes the system initialization handlers. However, I am having trouble understanding exactly where/how these handlers are registered. There are a couple of calls at the top of rtems_initialize_executive() to a couple of macros, RTEMS_LINKER_SET_BEGIN and RTEMS_LINKER_SET_END, with _Sysinit as an argument. However, I can't seem to find where _Sysinit is set nor can I find where the _Sysinit handler set gets initialized.<br>
<br>
Can someone enlighten me?<br>
<br></blockquote><div><br></div><div>It is magic and beautiful once you get a handle on it. :)</div><div><br></div><div>It is like C++ constructors but sorted. Each "constructor" or step in the initialization sequence has a sequence number associated with it. The RTEMS_SYSINIT_ITEM macro defines the record that goes into this section for the linker to sort. This example is from cpukit/rtems/src/tasks.c:</div><div><br></div><div><div>RTEMS_SYSINIT_ITEM(</div><div>  _RTEMS_tasks_Manager_initialization,</div><div>  RTEMS_SYSINIT_CLASSIC_TASKS,</div><div>  RTEMS_SYSINIT_ORDER_MIDDLE</div><div>);</div></div><div> </div><div>The beautiful part is that what once was a hard-coded set of calls is now dynamically constructed and **EVEN BETTER**, the linker can leave out calls to initialize things you don't use.</div><div><br></div><div>The entire set of order defining macros is in cpukit/score/include/rtems/sysinit.h.  </div><div><br></div><div>I was a little apprehensive about this when I taught an RTEMS class a couple of weeks ago. Any time you explain something for the first time, I could have done a good or bad job or it could just be hard to understand. But showing it in action was actually easy to explain. I set a "display/x *cur->handler" in gdb and "nexted" over the functions. It was obvious what was being called. And following the master list, we could see what wasn't called.</div><div><br></div><div>My only real feedback for code updates from teaching it was that we should review the names of the "step macros". Some of them have less than obvious names.</div><div><br></div><div>If someone doesn't point us to a better description of this in the documentation, then this email and follow up probably needs to be turned into something that can be incorporated into user documentation.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-- Travis<br>
<br>
<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
</blockquote></div><br></div></div>