[RTEMS Project] #3870: libc_reent set up is broken

[RTEMS trac]

#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       |   Keywords:
Blocked By:               |   Blocking:  3859
--------------------------+--------------------
 The patch ...

 https://git.rtems.org/rtems/commit/?id=69aa33490b1cd357519ab70b15ad150e11bb752e

 ... removes pieces of the initialisation of newlib's re-entrant struct.
 Are they are needed? I think they are. This breaks code such as telnet
 clients is subtle and difficult to find ways.

 With this change you cannot assign anything to `stdint` or `stdout` unless
 a suitable call to newlib is made that has the internal `CHECK_INIT()`
 macro. Any assignment is wiped out as `_sdidinit` is `false` and that
 results in `_sinit` being called.

 Is the lazy init in newlib on purpose? If so should `__getreent` in our
 `libcsupport` be returning a struct that is not initialised?

 Is the change in the linked patch standards compliant?

 A simple grep of code for an assignment of `libc_reent` did not show how
 this TCB field was initialised and it is not apparrent or easy to find.
 Why is the code written this way? There are no comments with
 `_Thread_Control_add_ons` and `Thread_Configured_control` explaining what
 are doing and how to use them and how they get loaded into the TCB.

--
Ticket URL: <http://devel.rtems.org/ticket/3870>
RTEMS Project <http://www.rtems.org/>
RTEMS Project