The thread model in newlib

[Jeff Johnston]

Leif Ekblad wrote:
> 
>> Have you looked at more recent sources?  For example, there is now a 
>> __DYNAMIC_REENT__ flag which tells newlib you will be providing a 
>> routine __getreent() to select the current thread's reentrancy structure.
> 
> 
> OK. It seems like this macro is defined in config.h if the __linux__ define
> is active. I suppose I can change here to make it active for __RDOS__
> as well.
> 
> Besides, I remember why I had to patch for this in 1.10. Without a
> function call to get the current thread's reent structure, you must
> modify the pointer with every thread-switch. This was pretty much
> out of the question since RDOS have kernel threads.
> 
>>  This removes the need of the user-code to call _r routines with a 
>> specific reentrant structure (the _REENT macro is redefined to call 
>> __getreent()).
> 
> 
> Yes, is this a major improvement.
> 
>>  In the internal code, for example, you just include errno.h and set 
>> errno directly.  The macros take care of everything so that the 
>> __getreent() function gets called under the covers and the errno value 
>> is placed in the correct thread context.  In your situation, you could 
>> write a __getreent() routine that referred to a special pointer in TLS 
>> that is initialized at thread creation.
> 
> 
> Yes, this is how I patched 1.10 too. I let the thread-creation code
> allocate a FS selector unique to each thread. Since a thread-switch
> saves all registers, this works as it should.
> 
>> Also note there is a implementation of linuxthreads in the 
>> libc/sys/linux /linuxthreads directory that builds for i386.  Newlib 
>> altered the linuxthreads code to add the initialization of the 
>> reentrant structure for new threads and placing the pointer in a 
>> control structure to be accessed at any time.  If you supply most or 
>> all of the syscalls that Linux does, you probably can use a great deal 
>> of the thread code.
> 
> 
> Isn't linuxthreads an application implementation of threads rather than
> a kernel implementation?
> 

It's the old glibc thread implementation prior to NPTL.  I mentioned it 
merely to be helpful.

>> Regarding your request to not supply _r routines:  the Linux port 
>> specifies -DMISSING_SYSCALL_NAMES in configure.host as it directly 
>> supplies reentrant syscalls (i.e. no _r syscalls are required).  You 
>> would want to do this as well.
> 
> 
> OK, I can see how this works.
> I see that the Linux implementation has lots of code in newlib. Is this
> the preferred way to support a new OS? I also see that some systems
> use newlib/libc/sys while some others use libgloss/sys. What is the
> difference and what exactly is libgloss?
> 

Libgloss is the place for embedded board support package libraries 
whereas newlib/libc/sys is for OSes (e.g. RTEMS, Linux, Cygwin). There 
are few platforms like ARM that are in libc/sys but this is just 
historical and they truly belong in libgloss.  The libgloss library 
allows an end-user to choose at compile/link time the actual target 
board/simulator.  Having ARM in newlib has proven a true nuisance so a 
libgloss directory has been created and eventually we'll have gcc use it 
exclusively and remove the libc/sys/arm directory altogether.

RTEMS and Cygwin actually use newlib as a base that they override and 
enhance so the syscalls, OS-specific functions are actually found in 
their own projects.  OTOH, the linux support was started in newlib and 
has grown to where it is today.  It too overrides functionality from the 
shared sections of newlib as appropriate for Linux.

-- Jeff J.