Where exactly do system initialization handlers get registered?

[Travis Wheatley]

Thanks Joel,

Thanks for the explanation of the "magic".  So, as I understand it this list gets populated by calls to the RTEMS_SYSINIT_ITEM macro and uses a rather inventive indexing scheme that gets sorted and populated at link time. Unfortunately, this would seem to leave me with a difficult debugging conundrum. Unfortunately, the IDE I am using for debugging seems to have some quirks, one of which is that the "step into" feature is not working. Since my kernel panic seems to be happening during the previously mentioned while loop that invokes the system initialization handlers I am at a loss for how to know exactly which chunks of code are being called as one iterates through this loop (so I can set breakpoints in them to determine which one in the chain is behaving badly).

So.... other than looking at all uses of RTEMS_SYSINIT_ITEM in the entire source tree and attempting to guess which ones are a part of the _Sysinit group, is there a better way of identifying those bits of code?

-- Travis


On Apr 1, 2016, at 12:19 PM, Joel Sherrill wrote:



On Fri, Apr 1, 2016 at 12:09 PM, Travis Wheatley <travis.wheatley at emergentspace.com<mailto:travis.wheatley at emergentspace.com>> wrote:
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.

Can someone enlighten me?


It is magic and beautiful once you get a handle on it. :)

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:

RTEMS_SYSINIT_ITEM(
  _RTEMS_tasks_Manager_initialization,
  RTEMS_SYSINIT_CLASSIC_TASKS,
  RTEMS_SYSINIT_ORDER_MIDDLE
);

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.

The entire set of order defining macros is in cpukit/score/include/rtems/sysinit.h.

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.

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.

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.

--joel

-- Travis


_______________________________________________
users mailing list
users at rtems.org<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users

_______________________________________________
users mailing list
users at rtems.org<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160401/2287959a/attachment-0002.html>