Quantcast

Externally provided __getreent

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Externally provided __getreent

Olivier Desenfans
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Externally provided __getreent

Sebastian Huber-4
On 19/05/17 16:44, Olivier Desenfans wrote:
> 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.

This is not how weak symbols work. If the linker has no reason to look
for your __getreent() function (e.g. because it found the weak version
first and nothing else pulled in the module containing your
implementation), then it will not end up in the executable.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Loading...