* 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).