Where exactly do system initialization handlers get registered?

[Joel Sherrill]

On Apr 1, 2016 1:29 PM, "Travis Wheatley" <travis.wheatley at emergentspace.com>
wrote:
>
> 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?

Objdump the special section for the actual list.

But if printk is working, just print the address of the method before it is
invoked. Then you can look that up.

Crappy debug situation. I am helping someone with a native Linux program
under Eclipse and the bizarre debugger things I have see so far have
resulted in me teaching him how to use the command line gdb to debug.
Fprintf to stderr isn't even captured in the Eclipse output. And this is
native Linux!

>
> -- 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> 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
>>
>>
>> _______________________________________________
>> 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/87fd3f20/attachment-0002.html>