Bringing the Scheduling Simulator in synch with RTEMS master
Joel Sherrill
joel at rtems.org
Wed Apr 6 12:49:25 UTC 2016
Newlib has a Linux configuration and we don't assume a lot of the host.
Using newlib as the native libc rather than glibc may solve these problems.
The only gotcha I can see is that the Linux newlib target has a fair amount
of code in the OS support directory for Linux. If they replace too much
normal newlib, it may not work still.
But that's a better long term solution. We depend more on the BSD-isms in
newlib than we did years ago. At one point, there were no dependencies.
On Apr 1, 2016 9:13 AM, "Darshit Shah" <darnir at gmail.com> wrote:
> On 03/30, Joel Sherrill wrote:
>
>> On Wed, Mar 30, 2016 at 9:03 AM, Darshit Shah <darnir at gmail.com> wrote:
>>
>> I've started trying to bring the scheduling simulator in synch with the
>>> current RTEMS master. Joel has created Trac Ticket #2679 (
>>> https://devel.rtems.org/ticket/2679) for this task.
>>>
>>> While trying to get the simulator to compile, GCC spits out the following
>>> error:
>>>
>>> In file included from
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/threadq.h:25:0,
>>> from
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/thread.h:35,
>>> from
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/heap.h:22,
>>> from
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/types.h:26,
>>> from
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/rtems/include/rtems/rtems/config.h:24,
>>> from
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/sapi/include/rtems/config.h:57,
>>> from
>>> ../../../rtems-schedsim/schedsim/rtems/rtems_init.c:25:
>>>
>>> /home/thedoctor/Programming/rtems/rtems/cpukit/score/include/rtems/score/rbtree.h:21:22:
>>> fatal error: sys/tree.h: No such file or directory
>>>
>>> Some scouting around reveals that the sys/tree.h header file is available
>>> in Newlib. However, I am unable to find a way to point the compiler in
>>> that
>>> direction for the scheduling simulator. Can someone please point me to
>>> the
>>> right set of Automake directives I'd require for this?
>>>
>>>
>>> There are two alternatives for missing libc files like this.
>>
>> 1) hope they really aren't needed and ifdef out the include. I suspect
>> this
>> won't work here.
>>
>> That could work for a few cases, but in this case I doubt that'll help.
>
> 2) put a copy in schedsim/rtems/sched_cpu/sys. Looks like I hit other
>> issues like a missing
>> cpuset.h method and had to add a stub sys/lock.h.
>>
>> Is this the only solution we have? Because, I see a few new issues where
> newlib now has a newer version of the BSD time.h file and the schedsim
> fails to build without it. Currently, the only way is to copy all those
> header files into schedsim/rtems/sched_cpu/sys. Would it possible to extend
> schedsim to directly use newlib just like the RTEMS build does? Then we
> won't need to copy all these files around and keep duplicate copies.
>
> Add a section to the instructions in the ticket. I forgot about this case.
>>
>> Hopefully this isn't a bad thing to fix. Since you are layering BSD
>> capabilities on top of
>> glibc, it can be tricky to avoid naming conflicts.
>>
>> --joel
>>
>>
>>
>>> --
>>> Thanking You,
>>> Darshit Shah
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
> --
> Thanking You,
> Darshit Shah
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160406/ec8f414a/attachment-0002.html>
More information about the devel
mailing list