newLib integration

[Michael Fischer]

Hello Aurel,

if your YAGARTO toolchain comes from the YAGARTO page,
you will find a syscall.c example near the download
link from the toolchain too.

Perhaps this will solve your problem?

Best regards,

Michael
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Hi Michael

>if your YAGARTO toolchain comes from the YAGARTO page,
>you will find a syscall.c example near the download
>link from the toolchain too.
IMO this means you have to implement the functions (see syscalls.c) for your specific OS (newlib can't do that for
you).

As an example, with the "_sbrk_r" function the newlib wants to allocate new memory, so you have to implement the right
calls for your specific OS.

But now the problem, acctually i'm not aware of such deep details of the Nut/OS and hoped that someone else has already
done this for the Nut/OS.



Am i the only person who has encountered such a problem? Or is the solution so trivial that nobody sees the need for
talking about the solution?



By the way, the problems starts with enabling "Floating Point" in the Nut/OS Configurator (as stated in the example
page of the NutWiki) independent on the example.



Regards,

Aurel Thomi
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Faas, Hylke]

Hi Aurel and other readers,

To awnser your question, if you are the only person with this problem; I
don't think so, I do also have problems linking my object files.

The strange thing is that after activating floating point in the Nut/OS,
there is no application that can link, not even an application with no
code in it (except an empty main() function) won't link.
I have to say that, I also am a newbie with Nut/OS, but it doesn't look
good if an empty source can't link.


I got the link error also when I try to compile and link (without the
floating point enabled) a project of my own (with multiple source
files). If I look on the internet, they all talk about the malloc and
(s)printf functions that causes these errors because of the missing
syscalls.c or (all what Aurel allready told), but if I make a simple
project with a few (s)printf and malloc/free calls there are no errors.
I can even run the app on the Ethernut without problems, still I can't
link my own project.


Is there someone with more experience about this problem who can help us
(with the following questions for example)?
 - Does anyone know what realy causes the linking errors, what type of
functions or library for example?
 - What do we have to do so we don't get these errors?


Regards,

Hylke Faas


-----Original Message-----
From: en-nut-discussion-bounces@...
[mailto:en-nut-discussion-bounces@...] On Behalf Of
athomi@...
Sent: Sunday, June 14, 2009 11:40
To: fischermi@...
Cc: en-nut-discussion@...
Subject: Re: [En-Nut-Discussion] newLib integration

Hi Michael

>if your YAGARTO toolchain comes from the YAGARTO page, you will find a
>syscall.c example near the download link from the toolchain too.
IMO this means you have to implement the functions (see syscalls.c) for
your specific OS (newlib can't do that for you).

As an example, with the "_sbrk_r" function the newlib wants to allocate
new memory, so you have to implement the right calls for your specific
OS.

But now the problem, acctually i'm not aware of such deep details of the
Nut/OS and hoped that someone else has already done this for the Nut/OS.



Am i the only person who has encountered such a problem? Or is the
solution so trivial that nobody sees the need for
talking about the solution?



By the way, the problems starts with enabling "Floating Point" in the
Nut/OS Configurator (as stated in the example
page of the NutWiki) independent on the example.



Regards,

Aurel Thomi
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Hi

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.



Regards,

Aurel Thomi
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Thiago A. Corrêa]

Hi,

On Wed, Jun 17, 2009 at 12:41 PM, athomi@... <athomi@...> wrote:
>
> IMO the question seems to be easy: How to make _sbrk reentrant (_sbrk_r)?
>

Given that the Nut/OS only has cooperative threads, not preemptive
threads, then it already is reentrant :)

On the other hand, one easy way might be protect it with
NutEnterCritical/NutLeaveCritical. Probably not the most eficient way,
but should work.

> => 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.
>

Do you really need to build reentrant newlib? As I mentioned above, it
doesn't make much sense in Nut/OS right now.


Kind Regards,
   Thiago A. Correa
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Hi,

>Given that the Nut/OS only has cooperative threads, not preemptive
>threads, then it already is reentrant :)
Crucial point, i haven't thought it to the end before.

>Do you really need to build reentrant newlib? As I mentioned above, it
>doesn't make much sense in Nut/OS right now.
You may be right, but this dosn't solve the problem with the actual YAGARTO version because that version _is_ build
as reentrant.



So i see two solutions:

- Trying to get an up-to-date version of YAGARTO build without reentrant (resp. diverting to such an older version)

  ==> might it be worth a note on the NutWiki?

- Create some "wrapper" (to the already available non-reentrant stubs) functions for the reentrant stubs of newlib



Either way, thank a lot for your answers.



regards,

Aurel Thomi

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Hi Thiago

>Given that the Nut/OS only has cooperative threads, not preemptive
>threads, then it already is reentrant :)
I thought about your point but came to the conclusion that i have to disagree.
IMO making newlib reentrant means among others not to use global variables. Acctually newlib uses the variable
"errno" as a global variable (see the already mentioned article about porting newlib) and this variable has to be
"converted" into a (at least) task specific variable.

Cooperative or not, you can't garantee that a newlib call (which may set the "errno" global variable) is always
followed by the check of the function's "return value" (in this case the "errno" variable).



You might argue, that if we define a "design rule" that a newlib call has to be followed by its check of the errno (and
is not interruptable -- exept of interrupt service routines -- by the cooperative Nut/OS), then the non-reentrant
newlib functions may work. But i wouldn't count on the awareness of this "design rule" of all developers.



Regards,

Aurel

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

[Nathan Moore-5]

On Sat, Jun 20, 2009 at 7:10 AM, athomi@... <athomi@...>wrote:

>  Acctually newlib uses the variable
> "errno" as a global variable (see the already mentioned article about
> porting newlib) and this variable has to be
> "converted" into a (at least) task specific variable.


errno not being thread local makes it almost entirely useless for anything
at all.  I don't typically make use of it
in Nut, but if I did I'd have tried to move it to the thread structure and
turn errno into a macro that referenced that.
In most cases of errors I can't come up with a recovery strategy that errno
could be used for, so it's not that great
outside of testing or other instances where there's human interaction or a
log to report it to.

Nathan
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion