Documentation reentrancy
Carl Denzen Van
carl@vandenzen.nl
Mon Mar 6 05:13:00 GMT 2006
I send this message again, because it has been refused due to html
formatting problems.
So far so good. But how do I (in a clean way) get rid off the newlib-
provided __getreent() in getreent.c (libc.a)?
Any tips about how to integrate newlib with an rtos would be welcome.
I want to use nilsen elektronik rtos. Do I make the newlib syscalls
separately, should I put them in the newlib source tree or should I
put them in the rtos source tree?
What does libgloss mean?
Cheers
Carl.
This is the error I get about getreent():
/sw/bin/m6811-elf-gcc -g -Os -mshort -I../nilsen-proc -save-temps -
Wl,-m,m68hc11elf -nostdlib -L ../nilsen-proc -L /usr/local/m6811-elf/
lib/mshort -L /usr/local/m6811-elf/lib/ldscripts -L ../newlib -L /sw/
share/m6811/lib/gcc-lib/m6811-elf/3.0.4/mshort -o trein1.elf ../
nilsen-proc/start.o trein1.o -lc -lnewlib-nilsen-proc-syscalls -
lnilsen-proc -lgcc
../newlib/libnewlib-nilsen-proc-syscalls.a(syscalls.o): In function
`__getreent':
syscalls.i:(.text+0x14d): multiple definition of `__getreent'
/usr/local/m6811-elf/lib/mshort/libc.a(getreent.o):../../../../../../
newlib-1.14.0/newlib/libc/reent/getreent.c:8: first defined here
/sw/bin/../share/m6811/lib/gcc-lib/m6811-elf/3.0.4/../../../../m6811-
elf/bin/ld: Disabling relaxation: it will not work with multiple
definitions
collect2: ld returned 1 exit status
make: *** [trein1.elf] Error 1
Op 1-mrt-2006, om 0:27 heeft Jeff Johnston het volgende geschreven:
> The __DYNAMIC_REENT__ flag is currently set manually in libc/
> include/sys/config.h. It is looked at by libc/include/sys/reent.h
> which then defines _REENT to be a call to __getreent() instead of
> the default which is to define _REENT to be _impure_ptr.
>
> The libgloss reference was for you to look at a working libgloss
> implementation to figure out how to write a libgloss library. It
> has nothing to do with your reentrancy problem.
>
> -- Jeff J.
>
> It is not documented
>
> Carl Denzen Van wrote:
>> Hello Jeff,
>> I cannot figure out how to "Set the __DYNAMIC_REENT__ flag for
>> the platform" (and I think you named it also
>> "__DYNAMIC_REENTRANCY__"). Where can I find documentation?
>> Do I have to call the _getreent() myself in the stubs? Or is it
>> already implemented at another level in newlib?
>> In the working libgloss/mn10300 I did not find anything about
>> reentrancy in the way you explained.
>> Carl.
>> Op 16-feb-2006, om 0:21 heeft Jeff Johnston het volgende geschreven:
>>> Carl Denzen Van wrote:
>>>
>>>> Thank you. I will implement choice 4.
>>>
>>>
>>>
>>>> And meanwhile I ran into the next errors when I compile the
>>>> simple stubs from the docs:
>>>
>>>
>>> I wouldn't suggest implementing those strictly from the docs as
>>> they have the wrong names to start with and there is already an
>>> implemented library of these stubs available for you in libgloss/
>>> libnosys (sans _exit and crt0 which you should provide in
>>> assembler). You simply add -lnosys to the end of your link or
>>> embed the reference in your ld script or spec file.
>>>
>>> I usually suggest looking at working implementations (e.g.
>>> libgloss/ mn10300).
>>>
>>> -- Jeff J.
>>>
>>>
>>>
>>>> stubsc.c: In function `sbrk':
>>>> stubsc.c:108: `stack_ptr' undeclared (first use in this function)
>>>> stubsc.c:108: (Each undeclared identifier is reported only once
>>>> stubsc.c:108: for each function it appears in.)
>>>> stubsc.c:110: warning: implicit declaration of function `_write'
>>>> stubsc.c: At top level:
>>>> stubsc.c:122: conflicting types for `stat'
>>>> /usr/local/m6811-elf/include/sys/stat.h:124: previous
>>>> declaration of `stat'
>>>> stubsc.c:131: warning: `struct tms' declared inside parameter list
>>>> stubsc.c:131: warning: its scope is only this definition or
>>>> declaration, which is probably not what you want.
>>>> stubsc.c: In function `write':
>>>> stubsc.c:162: warning: implicit declaration of function `writechar'
>>>> Another improvement to the documentation would be to mention
>>>> the files to be included. I include (after "grep"ping an
>>>> evening for the missing entries):
>>>> #include <sys/types.h>
>>>> #include <sys/stat.h>
>>>> #include <stdlib.h>
>>>> #include <errno.h>
>>>> #undef errno
>>>> extern int errno;
>>>> Carl van Denzen. (trying to make it running on Motorola 6811)
>>>> Op 15-feb-2006, om 23:29 heeft Jeff Johnston het volgende
>>>> geschreven:
>>>>
>>>>> Carl van Denzen wrote:
>>>>>
>>>>>> I am working on a very simple application, but do not know
>>>>>> what is the best solution. The documentation is not clear
>>>>>> enough (for me).
>>>>>> From the mailing list, the preferred way is NOT to use the
>>>>>> _xxxx_r functions. Mention this preference in the docs.
>>>>>> The documentation phrase "Each function which uses the
>>>>>> global reentrancy structure uses the global variable
>>>>>> _impure_ptr, which points to a reentrancy structure." is
>>>>>> confusing. Is there really a GLOBAL reentrancy structure?
>>>>>
>>>>>
>>>>>
>>>>> Yes. I guess it would be clearer to call it the default
>>>>> reentrancy structure that is of global-scope. It is used by
>>>>> functions that have
>>>>> both a regular and _r form. The regular form of the function
>>>>> calls the _r version, passing the default reentrancy
>>>>> structure "or" if __DYNAMIC_REENTRANCY__ is set to true, it
>>>>> calls the function __getreent() to get a reentrancy structure
>>>>> which is then passed to the _r version.
>>>>>
>>>>> This leads to the following choices:
>>>>>
>>>>> 1. With no threading, just let functions use the default
>>>>> reentrancy
>>>>> struct (i.e. do nothing and don't worry about calling _r
>>>>> routines).
>>>>> 2. Call _r routines only and manually pass an appropriate
>>>>> reentrancy
>>>>> struct (one allocated per thread).
>>>>> 3. Update the _impure_ptr manually at thread switches and call the
>>>>> regular forms of functions (i.e. don't worry about calling _r
>>>>> suffixed functions).
>>>>> 4. Set the __DYNAMIC_REENT__ flag for the platform and
>>>>> provide a __getreent() function that returns a unique
>>>>> reentrancy
>>>>> struct for the current running thread. Call regular forms
>>>>> of functions.
>>>>>
>>>>>> An improvement to the documentation would be an addition to
>>>>>> choice 2 (which I think is the preferred choice): "The
>>>>>> global _impure_ptr should be set to point to the thread-
>>>>>> dependent _reent at every thread switch by the OS".
>>>>>>
>>>>>
>>>>> Actually, I would say choice 4 is the preferred choice for
>>>>> threaded
>>>>> newlib.
>>>>>
>>>>>> Cheers,
>>>>>> Carl
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
More information about the Newlib
mailing list