This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The thread model in newlib


Jeff J:
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.

OK, I see.


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.

I'm not quite sure what to put into newlib and what to keep in my own
project. For example, I've done a 150k GAS interface file, rdos.s, for all syscalls
in RDOS. This file is anticipated to change quite often as I add new syscalls.
For sure the implementation of the required fiunctions in newlib will require
linking to this object file. I configured GCC to always link this file and also
embedded the crt-startup code there. Should I put this file in newlib or keep
it in my project? Or both?


There is also a shared rdos.h file in my project that contains prototypes for
rdos.s that is used by both Win32 and GCC. This file must be both in
newlib and in my project.


Regards,
Leif Ekblad





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]