[RTEMS Project] #3870: libc_reent set up is broken
RTEMS trac
trac at rtems.org
Tue Feb 11 06:17:39 UTC 2020
#3870: libc_reent set up is broken
-------------------------+---------------------
Reporter: Chris Johns | Owner: (none)
Type: defect | Status: new
Priority: high | Milestone: 5.1
Component: score | Version: 5
Severity: normal | Resolution:
Keywords: | Blocked By:
Blocking: 3859 |
-------------------------+---------------------
Comment (by Sebastian Huber):
Replying to [comment:1 Chris Johns]:
> The re-entrant struct is initialised the same way in the patch as before
so the original initialisation does not allow access to `stdin` or
`stdout` until after a suitable newlib call has been made.
The re-entrant struct is initialized by newlib_create_hook() and destroyed
by newlib_terminate_hook(). There is a test case for this area:
libtests/newlib01.
>
> There is no public interface to call `__sinit`, a call to newlib has to
be made. The newlib code uses an internal macro called `CHECK_INIT` and it
does:
>
> {{{
> if ((_check_init_ptr) && !(_check_init_ptr)->__sdidinit) \
> __sinit (_check_init_ptr);
> }}}
>
> I wonder if our `__getreent` could ...
> {{{
> struct _reent *__getreent(void)
> {
> struct _reent *_reent_ptr = _Thread_Get_executing()->libc_reent;
> if (!_reent_ptr->__sdidinit)
> feof(_reent_ptr->stdout);
> return _reent_ptr;
> }
> }}}
> ?
The __getreent() should not do any initialization steps.
Sorry, I don't know the problem you want to solve.
--
Ticket URL: <http://devel.rtems.org/ticket/3870#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project
More information about the bugs
mailing list