Externally provided __getreent

[Olivier Desenfans <olivier dot desenfans at hipperos dot com>]

Hello,

I am currently experimenting with newlib to try and use it with our
in-house embedded real-time operating system. I hit a problem when
trying to implement the __getreent function. We already have a
thread-local information structure in our custom API. The simple way
to do this for me would be to simply add a struct _reent to this
structure, make an accessor function, call it __getreent and be done
with it. This would all be in our custom API to avoid code duplication
(at least for the moment).

newlib apparently does not let me do that; you can override the
default implementation (in sys/reent/getreent.c) by implementing your
own version (in sys/myos/getreent.c). I tried to declare that custom
version as a weak symbol so that the linker would replace it with the
version in our custom API but to no avail. Interestingly the linker
does not throw a duplicate symbol error. There seems to be some magic
trickery in the build system that prevents me from achieving this.

Therefore I wanted an opinion on a few things:
- Is what I want possible? Should there be a patch to add a way to
supply __getreent externally (i.e. GETREENT_PROVIDED, just
  like it is done for malloc)?
- In the end my problem is that for various reasons I'd have to
reimplement arch-dependent code to retrieve the _reent struct
  for all the architectures we support (x86, PPC64, ARMv7/8, ...) in
newlib as well as our thread info structure. I can avoid this
  duplication at the cost of a link dependency to our own API. Is it a
good idea/does it follow the philosophy of newlib?

Thanks,

Best regards,

Olivier Desenfans