[En-Nut-Discussion] newLib integration

athomi at bluewin.ch athomi at bluewin.ch
Wed Jun 17 17:41:03 CEST 2009


To summarize all the documents i have read about porting the newlib to an operating system (even on a bare 
microprocessor) i came to the following conclusion:
newlib build with the reentrant options requests a set of 17 stubs (functions called by newlib to get certain 
things to be done, like allocate some memory, write an stream to a device etc.).

This stubs are very operating system specific (as syscalls.c does only give you an idea of how your implementation for 
your operating system might be looking) and may be also architecture dependent.

Not all stubs need to be implemented because some newlib functions only need specific stubs.

Acctually the stubs for "non-reentrant" build of the newlib are done and comes with NutOS (i.e. ./crt/sbrk.c, the non-
reentrant version of _sbrk_r which was the cause why i asked such a question on this maillist).

IMO the question seems to be easy: How to make _sbrk reentrant (_sbrk_r)?

=> I found an interesting article from Bill Gatliff on the Embedded.com Magazin (Embedding GNU: Newlib, Part 2) where 
he describes how to port newlib (as the name of the article implies).

Why didn't i already port the reentrant newlib to the actual NutOS?

=> Because i don't have the detail knowledge of the NutOS internals to do this task in an usefull time.

Before starting such a challenging task (although a charming one) i'd like to clarify the following points:

- Has anybody else already done this task?

- Is someone already doing this work? Or does somebody plan to do this task?

- Do i understand the task right? And seems my understanding of the aims and their solutions to be correct?

By the way, an older version of yagarto "yagarto-bu-2.18_gcc-4.3.2-c-c++_nl-1.16.0_gi-6.8.50_20080928" seems to have 
been build newlib without reentrant options. With this yagarto version the examples compiled with no errors.

It might work also with the yagarto version "yagarto-bu-2.19.1_gcc-4.3.3-c-c++_nl-1.17.0_gi-6.8.50_20090311", but i 
haven't verified this yet.

Might someone confirm my conclusion or even point me the fault in my thoughts.


Aurel Thomi

More information about the En-Nut-Discussion mailing list