Where exactly do system initialization handlers get registered?

Joel Sherrill joel at rtems.org
Fri Apr 1 17:19:11 UTC 2016


On Fri, Apr 1, 2016 at 12:09 PM, Travis Wheatley <
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
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20160401/9a047064/attachment.html>


More information about the users mailing list