From: Olivier Desenfans <olivier.desenfans@hipperos.com>
To: newlib@sourceware.org
Subject: Externally provided __getreent
Date: Fri, 19 May 2017 14:44:00 -0000 [thread overview]
Message-ID: <CAE2L740FW-chs4dVvQhpS9LXCXNgHF+xLWaEJP0gcpFFEsw02A@mail.gmail.com> (raw)
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
next reply other threads:[~2017-05-19 14:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-19 14:44 Olivier Desenfans [this message]
2017-05-22 5:36 ` Sebastian Huber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE2L740FW-chs4dVvQhpS9LXCXNgHF+xLWaEJP0gcpFFEsw02A@mail.gmail.com \
--to=olivier.desenfans@hipperos.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).