public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* Externally provided __getreent
@ 2017-05-19 14:44 Olivier Desenfans
  2017-05-22  5:36 ` Sebastian Huber
  0 siblings, 1 reply; 2+ messages in thread
From: Olivier Desenfans @ 2017-05-19 14:44 UTC (permalink / raw)
  To: newlib

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Externally provided __getreent
  2017-05-19 14:44 Externally provided __getreent Olivier Desenfans
@ 2017-05-22  5:36 ` Sebastian Huber
  0 siblings, 0 replies; 2+ messages in thread
From: Sebastian Huber @ 2017-05-22  5:36 UTC (permalink / raw)
  To: Olivier Desenfans, newlib

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  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-05-22  5:36 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-19 14:44 Externally provided __getreent Olivier Desenfans
2017-05-22  5:36 ` Sebastian Huber

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).