disable newlib
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Aug 18 17:09:18 UTC 2008
Manuel Coutinho wrote:
> We are using RTEMS 4.8.0 and the Leon2 BSP. I guess there are some
> differences with the 4.9 version and with ARM...
>
>
>
There are lots of cross target dependencies addressed
after 4.8.0 which make executables smaller.
The code density on Thumb is MUCH MUCH better
than on SPARC. The erc32 BSP has had a LOT of
attention paid to it and although there may be
improvements left, I don't know of any.
For leon2, the minimum is currently at:
text data bss dec hex
57760 2404 2248 62412 f3cc
with a workspace size of 3248 bytes.
No analysis has been made on the LEON2 BSP in relation
to size. A quick glance shows that it suffers from the
same debug IO pulls in the console pulls in termios
that we just discussed for the mcf52235 BSP. So it
it is likely also 50% too large if the mcf52235 is any
indication.
--joel
>> -----Original Message-----
>> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
>> Sent: Monday, August 18, 2008 5:01 PM
>> To: Manuel Coutinho
>> Cc: 'xu ray'; rtems-users at rtems.com
>> Subject: Re: disable newlib
>>
>> Size info included. I hope the bfin and mcf52335 persons
>> read this.
>>
>> Manuel Coutinho wrote:
>>
>>> Hi
>>>
>>> We are trying to make possible a configuration (using the configure
>>>
>> script)
>>
>>> where RTEMS does not have newlib (open, close, malloc, etc) and other
>>>
>> things
>>
>>> so that a minimal footprint can be achieved.
>>>
>>> At this stage, we are just checking how much effort is required to
>>>
>> perform
>>
>>> this. I would suggest to place #ifdef inside the RTEMS source code so
>>>
>> that
>>
>>> the unnecessary calls are not made. However, there is more work needed
>>>
>> here.
>>
>>> I've tried to take out most of the calls to libc and other things that
>>>
>> we
>>
>>> don't need from the RTEMS source code (e.g rtems_termios_init, etc) and
>>>
>> the
>>
>>> footprint has been reduced from ~70 KiB to ~37KiB, but we need to go
>>>
>> further
>>
>>> and remove all dead code. Since RTEMS itself makes calls to newlib or
>>>
>> libc,
>>
>>> if the application does not make the extra calls it is not sufficient
>>> because the code will still be present.
>>>
>>>
>> What version are you looking at? rtems_termios_init is NOT
>> required at all. Some BSPs had dependencies in old RTEMS
>> versions but those have long been removed. I really hope
>> you guys are not hacking those old versions to this level.
>>
>> Not to be ugly but I doubt any analysis that starts with
>> that assertion. termios is only used if you have a console
>> driver and a console driver is NOT part of the minimum
>> configuration. Not even the clock tick driver is required.
>>
>> I would never claim that there is no room for improvement
>> but I think you are barking up the wrong tree. This is
>> the size of minimum.exe for arm/rtl22xx_t built from the
>> head with everything disabled.
>>
>> 23127 2468 2512 28107 6dcb arm rtl22xx_t minimum.exe
>>
>> The workspace required is only 1560 bytes.
>>
>> Attached is the symbol table which only has 427 lines!!!
>>
>> I only see 4 newlib methods in this (str*, mem*) and
>> then some RTEMS POSIX section 2 methods to build the device
>> tree in the mini-IMFS. That appears to be the only source
>> of calls to calloc and malloc in the executable as well.
>>
>> So I have hope that GSOC project Ray has mentored
>> should eliminate much of that. But memset() and memcpy()
>> are more than likely always going to be part of the footprint
>> because gcc can emit calls to them for structure operations.
>>
>> For the sparc/erc32, that size changes to
>>
>> 43792 2308 2204 48304 bcb0 minimum.exe
>>
>> with only 430 symbols in the symbol table. Workspace
>> required is 3256 bytes.
>>
>>> Now, we stumbled with the newlib source code that is very intertwined
>>>
>> with
>>
>>> RTEMS (mainly to make malloc reentrant, from what I can tell). This will
>>> need some detailed research to make sure everything works well.
>>>
>>>
>>>
>> I don't think you are seeing what you think you are seeing.
>> malloc is reentrant because it is using a mutex around a
>> SuperCore heap. The RTEMS malloc_r ignores the reentrancy
>> parameter. We do NOT use the code in newlib for malloc and
>> never have.
>>
>>>
>>>> -----Original Message-----
>>>> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
>>>> Sent: Monday, August 18, 2008 3:38 PM
>>>> To: xu ray
>>>> Cc: Manuel Coutinho; rtems-users at rtems.com
>>>> Subject: Re: disable newlib
>>>>
>>>> xu ray wrote:
>>>>
>>>>
>>>>> You can disable it with patch YanMiao is working on.
>>>>>
>>>>>
>>>> I don't see how you can disable the entire newlib library without
>>>> special tool builds.
>>>>
>>>> You can dynamically configure where the per-task reentrancy support is
>>>> disabled. That saves a fair amount of memory.
>>>>
>>>>
>>>>> But after doing this, lots of API (e.g. Posix ) and (most) C library
>>>>> can not be used.
>>>>>
>>>>>
>>>>>
>>>> If you build without newlib at all, this is true. The .h files from
>>>> RTEMS and
>>>> newlib are intertwined for the C library and POSIX threading.
>>>>
>>>>
>>>>> You can use this for small footprint MCU/CPU that has limited RAM on
>>>>>
>>>>>
>>>> chip.
>>>>
>>>> You can also just not call the services and not get code pulled in.
>>>>
>>>> I will reserve judgment until I see the patch. I tend to believe that
>>>>
>> you
>>
>>>> can build everything and just not call it in your application. If
>>>>
>> there
>>
>>>> are
>>>> pieces of RTEMS that are required that start to pull this in, then
>>>>
>> there
>>
>>>> is
>>>> a dependency issue.
>>>>
>>>> 95% of the time breaking dependencies is sufficient. Special
>>>>
>> conditional
>>
>>>> builds are seldom required.
>>>>
>>>> --joel
>>>>
>>>>
>>>>> 2008/8/18 Manuel Coutinho <manuel.coutinho at edisoft.pt
>>>>> <mailto:manuel.coutinho at edisoft.pt>>
>>>>>
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> Just a quick question:
>>>>>
>>>>> How can we disable newlib (I mean, undefine RTEMS_NEWLIB)? Can
>>>>> this be done in the configuration phase?
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> *Manuel Coutinho
>>>>> *Software Engineer - Space
>>>>>
>>>>> *EDISOFT, S.A.*
>>>>> Rua Quinta dos Medronheiros - Lazarim
>>>>> Apartado 382 Monte de Caparica
>>>>> 2826-801 Caparica Portugal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.com <mailto:rtems-users at rtems.com>
>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks & Best Regards!
>>>>>
>>>>> Ray, Xu
>>>>>
>>>>>
>>>> --
>>>> Joel Sherrill, Ph.D. Director of Research & Development
>>>> joel.sherrill at OARcorp.com On-Line Applications Research
>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>>> Support Available (256) 722-9985
>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Joel Sherrill, Ph.D. Director of Research & Development
>> joel.sherrill at OARcorp.com On-Line Applications Research
>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>> Support Available (256) 722-9985
>>
>>
>
>
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list