[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