Porting 1.14.0 to new OS
Jeff Johnston
jjohnstn@redhat.com
Fri Jul 14 20:30:00 GMT 2006
Anders Lindgren wrote:
> I am porting newlib to a new OS and have successfully created my own
> cross-toolchain and cross-built newlib (with stub syscalls) from within
> the GCC build for my new target. Now I am looking into the details of
> how to replace the stubs in sys/MyOS with real syscalls, and finishing
> things up.
>
> I think I've managed to get my head around most of the configuration
> and knobs, but I'd appreciate some help with the details. I am building
> a multithreaded newlib, with __DYNAMIC_REENT__ so I don't need to modify
> the (single memory space) kernel's thread-switching:
>
> o It is my understanding that some dummy files in newlib should be
> overridden by placing files with the same name in my sys/MyOS dir:
> reent/impure.c (libc TLS data for "MyOS"), reent/getreent.c
> (replace dummy __getreent()) and <sys/lock.h> (dummy lock defines).
> Is this the Right(tm) way to implement the multithread support, i.e.
> will C files and includes in my sys/MyOS dir override newlib's
> corresponding default stubs? Are there other files I need to override?
>
Yes. Object files of the same name will override the shared newlib ones
(i.e. you can choose to replace with asm or C as long as the object name
ends up the same). Header files are also overridden as you have noted.
I don't recommend overriding impure.c. If your platform doesn't
provide hardware support for TLS via a special register, I would suggest
you consider adding a generic tls pointer to the reentrant struct,
initialized to NULL.
> o To skip one layer of indirection, one can supply reentrant
> versions of libc syscalls (open, close etc) directly and define
> MISSING_SYSCALL_NAMES, make syscall_dir empty in configure.host
> (Linux does this?) and thus avoid getting stubs that only call
> _open_r etc anyway -- correct? Is there any reason I shouldn't
> do this?
>
No. If you do your syscalls properly, errno in the dynamic reent case
will be set correctly for the thread. A lot of _r stuff is in keeping
track of errno for the thread so you can skip the extra level of
indirection.
> o I understand _GLOBAL_REENT is only used to hold truly global data
> such as potentially shared FILE pointers that shouldn't be cleaned up
> when only a single thread exits, and that my __getreent()
> implementation should arrange for each new thread to have its own
> _reent structure allocated as needed. This brings up the question of
> _impure_ptr, _global_impure_ptr and _reclaim_reent(): I don't quite
> understand _reclaim_reent() in reent/reent.c:48 -- _impure_ptr is
> referenced explicitly, which seems wrong in a __DYNAMIC_REENT__ newlib.
> If it is meant to compare against the global _reent it should've been
> _GLOBAL_REENT (or at least _global_reent_ptr) -- but doing so would
> effectively turn the cleanup in stdlib/exit.c into a nop? Or is that
> what the comment about not returning malloc()'d memory is about?)
>
> o _wrapup_reent()/_reclaim_reent() aren't referenced anywhere afaict. I
> take it these are utility routines provided for my convenience, to be
> called in my thread implementation's thread-cleanup code?
>
Yes, you would want to use them there. They aren't referenced anywhere
else.
> o I was under the impression that in a __DYNAMIC_REENT__ newlib,
> _impure_ptr shouldn't even be defined at all, since all references
> to _reents should go through _REENT (== __getreent()) or _GLOBAL_REENT
> (which will only equal _impure_ptr in a single-threaded or
> !__DYNAMIC_REENT_ newlib). Please explain this relationship between
> _impure_ptr, _global_impure_ptr and _reclaim_reent(). It sounds like
> a pretty important, race condition prone thing I certainly don't want
> to get wrong! :-)
>
_impure_ptr is useful in startup. It won't get used in the dynamic case
unless your __getreent() chooses to use it as a default (e.g. before any
threads are kicked off from the main thread).
-- Jeff J.
> Ok, quite a few questions and clarification points at once, but I hope
> you at least find them reasonably informed questions -- I've tried to
> dig through the source and mailing lists[0] thoroughly, and appreciate
> any answers the list may have -- I really want to understand newlib
> internals properly.
>
> [0] And many thanks to Jeff for all of his excellent and patient answers
> on the list, which have contributed the bulk of my so far accumulated
> understanding of newlib's internals.
>
> Best Regards,
> Anders "ali" Lindgren
More information about the Newlib
mailing list