Hello,
i just started to write a posix layer for chibios, and of this reason i need a newlib built with the __DYNAMIC_REENT__ flag set. So any thread has its own reent struct accessible through the __getreent() function.
Is anywwhere such a prebuild lib available? The ARM GCC's with newlib that i found are multithreaded, but this usefull option is always not set
newlib port for chibios
Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: newlib port for chibios
Hi,
It is not something we control, the compiler maintainers have to decide this.
Consider that supporting that "impure pointer" thing would slow down the system and a multithreaded lib is not necessarily useful for everybody and larger.
Giovanni
It is not something we control, the compiler maintainers have to decide this.
Consider that supporting that "impure pointer" thing would slow down the system and a multithreaded lib is not necessarily useful for everybody and larger.
Giovanni
Re: newlib port for chibios
Thank you.
My hope was that here in this forum maybe someone else had the same problem and have perhaps already a suitable Toolchain.
greetings
My hope was that here in this forum maybe someone else had the same problem and have perhaps already a suitable Toolchain.
greetings
Re: newlib port for chibios
Giovanni wrote:Hi,
It is not something we control, the compiler maintainers have to decide this.
Consider that supporting that "impure pointer" thing would slow down the system and a multithreaded lib is not necessarily useful for everybody and larger.
Giovanni
Going thru the exercise right now, it's not that bad. Using the __DYNAMIC_REENT__ flag, and redefining the __getreent() means that it is only called when you make a newlib system call. No need to set the impureptr on each context switch. Whenever newlib needs the thread's struct reent, it just calls __getreent().
So, if you don't make any of those calls - no slow down.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: newlib port for chibios
Do you have an example for this?
I am reluctant to support this kind of things because it would depend on the library (newlib) and how the library is compiled (reentrant or not).
Giovanni
I am reluctant to support this kind of things because it would depend on the library (newlib) and how the library is compiled (reentrant or not).
Giovanni
Re: newlib port for chibios
Giovanni wrote:Do you have an example for this?
I am reluctant to support this kind of things because it would depend on the library (newlib) and how the library is compiled (reentrant or not).
Giovanni
Not sure if it should be part of standard ChibiOS distribution. Perhaps part of the optional syscalls, and have some #ifdefs based on the flavor of newlib included ..
CH_CFG_THREAD_EXTRAFIELDS: Add struct _reent newlib_reentry_structure.
CH_CFG_THREAD_INIT_HOOK(tp): Execute _REENT_INIT_PTR(tp->newlib_reentry_structure) to initialize struct _reent .
int *__errno(void)
{
return &_REENT->_errno;
}
struct _reent *__getreent()
{
return chThdGetSlefX()->newlib_reentry_structure;
}
Probably want to have a critical section in __errno.
I haven't tested this yet, but I have some other working code with CMX RTOS which looks similar. I'll update this thread when I have it working with ChibiOS.
Re: newlib port for chibios
Just wanted to report back here ...
You need to rebuild the arm-none-eabi-gcc toolchain. Get the toolchain source files, and apply this patch:
As you can see, it defines the "REENTRANT_SYSCALLS_PROVIDED" and "__DYNAMIC_REENT__" symbols that are required for the _REENT #define to be mapped to the __getreent() function.
I have tested the above, and am able to use the reentrant syscalls... Just follow the instruction ARM publishes in their source package. As of right now, they advise using Ubuntu 14.04 (if I remember correctly) to do the build. I created a VM and installed it in there ...
You need to rebuild the arm-none-eabi-gcc toolchain. Get the toolchain source files, and apply this patch:
Code: Select all
diff -Naru ../gcc-arm-none-eabi-7-2018-q2-update/build-toolchain.sh ./build-toolchain.sh
--- ../gcc-arm-none-eabi-7-2018-q2-update/build-toolchain.sh 2018-10-23 09:58:23.263306850 -0500
+++ ./build-toolchain.sh 2018-10-23 10:33:13.179050608 -0500
@@ -350,6 +350,7 @@
--enable-newlib-nano-formatted-io \
--disable-nls
+sed -i 's/^CFLAGS_FOR_TARGET.*/& -DREENTRANT_SYSCALLS_PROVIDED -D__DYNAMIC_REENT__/' Makefile
make -j$JOBS
make install
As you can see, it defines the "REENTRANT_SYSCALLS_PROVIDED" and "__DYNAMIC_REENT__" symbols that are required for the _REENT #define to be mapped to the __getreent() function.
I have tested the above, and am able to use the reentrant syscalls... Just follow the instruction ARM publishes in their source package. As of right now, they advise using Ubuntu 14.04 (if I remember correctly) to do the build. I created a VM and installed it in there ...
Who is online
Users browsing this forum: No registered users and 35 guests