Some questions on reentrancy, __DYNAMIC_REENT__ and _impure_ptr
Nick
cl26@nicolachel.net
Thu Apr 1 04:58:13 GMT 2021
Hi,
I've been trying to enable reentrancy of newlib on a home brew kernel
for the x86 platform and have some questions on how various pieces all
fits together.
Implemented __getreent () to return a private copy of struct reent, and
also hard coded __DYNAMIC_REENT__ and GETREENT_PROVIDED in sys/config.h
to rule out any issue of passing in via build CFLAGS or the CFLAGS in
configure.host. Things including errno seem to work but not totally
making sense.
As many library functions are still accessing the reent structure using
_impure_ptr instead of calling my __getreent () function, for example,
the CHECK_INIT (_REENT, fp) at the beginning of __swsetup_r (struct
_reent *ptr, register FILE * fp).
Questions:
1. Are the library functions expected to still use _impure_ptr instead
of calling __getreent () when both __DYNAMIC_REENT__ and
GETREENT_PROVIDED are hard coded in sys/config.h?
If so, how do they provide reentrancy? Since _impure_ptr is a global
pointer visible to all threads and threads can easily step on each
other's toes trying to change fields in the reent structure pointed to
by _impure_ptr concurrently.
If not, what other MACROs or changes should I make so that all the
library functions all use __getreent () instead of _impure_ptr? Is it
okay to set _impure_ptr to a bad value such as NULL in this case, in
order to catch any unintended access?
2. in the documentation on https://sourceware.org/newlib/, the following
is mentioned as needed for syscalls stubs to return errno:
#include <errno.h>
#undef errno
extern int errno;
If I do include this part, all the syscalls stubs seem to do when they
assign values to errno is setting the global int errno; inside reent.c.
As user code built against the library don’t read out that integer but
instead calls __(), errno set by syscall stubs can't be read out by user
code.
If on the other hand I don’t include this part before my syscall stubs,
the errno set by them do seem to work as they also set the copy in reent
structures. What might I have missed here?
3. There were some old discussions about manually changing _impure_ptr
at each context switch. But I’m wondering about the validity of such a
method since it seems like a really clumsy maneuver for kernel code at
CPL0 to reach into user space belonging to different binaries to change
a global pointer. What's more, if manually changing _impure_ptr at each
context switch is needed, then what would be the purpose of
__DYNAMIC_REENT__, GETREENT_PROVIDED and implementing a __getreent () to
get a thread local version?
4. Is _global_impure_ptr thread safe? It is a bit concerning as it seems
to be pointing to the same copy of impure_data that some libraries calls
would access, and even if I try to change _impure_ptr at each context
switch, some threads might still be accessing _global_impure_ptr
concurrently?
5. There were also old discussions about having to provide mutex for
malloc, is this still the case for newer versions of newlib like 4.10?
Thanks!
Nick
More information about the Newlib
mailing list