<p dir="ltr"><br>
On Apr 1, 2016 1:29 PM, "Travis Wheatley" <<a href="mailto:travis.wheatley@emergentspace.com">travis.wheatley@emergentspace.com</a>> wrote:<br>
><br>
> Thanks Joel,<br>
><br>
> 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).<br>
><br>
> 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?</p>
<p dir="ltr">Objdump the special section for the actual list.</p>
<p dir="ltr">But if printk is working, just print the address of the method before it is invoked. Then you can look that up.</p>
<p dir="ltr">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!<br></p>
<p dir="ltr">><br>
> -- Travis<br>
><br>
><br>
> On Apr 1, 2016, at 12:19 PM, Joel Sherrill wrote:<br>
><br>
>><br>
>><br>
>> On Fri, Apr 1, 2016 at 12:09 PM, Travis Wheatley <<a href="mailto:travis.wheatley@emergentspace.com">travis.wheatley@emergentspace.com</a>> wrote:<br>
>>><br>
>>> 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>
>><br>
>> It is magic and beautiful once you get a handle on it. :)<br>
>><br>
>> 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:<br>
>><br>
>> RTEMS_SYSINIT_ITEM(<br>
>>   _RTEMS_tasks_Manager_initialization,<br>
>>   RTEMS_SYSINIT_CLASSIC_TASKS,<br>
>>   RTEMS_SYSINIT_ORDER_MIDDLE<br>
>> );<br>
>>  <br>
>> 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.<br>
>><br>
>> The entire set of order defining macros is in cpukit/score/include/rtems/sysinit.h.  <br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> --joel<br>
>><br>
>>> -- 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">http://lists.rtems.org/mailman/listinfo/users</a><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">http://lists.rtems.org/mailman/listinfo/users</a><br>
><br>
><br>
</p>