On 07/11/2018 08:23, Ian Caddy wrote:
Or should this be fixed to check whether multi-tasking is running
before checking the currently running thread, we do this in some of
our other code?
Code which runs before the idle threads are created should not use
complex Newlib functions. Unfortunately snprintf() is a complex
Newlib function. I think we need a low level replacement for
snprintf() which could be used during BSP initialization for example.
This could be a simple wrapper for _IO_Printf().
I had a similar issue here:
https://lists.rtems.org/pipermail/devel/2018-September/023013.html
Thanks, I must have skipped over that one from a short time ago.
The problem is that we end up doing quite a lot of complicated things
before multi-tasking is started, and there is not going to be a simple
way around that for us with quite a large code base.
I am still wondering whether or not I can change the __getreent
function to detect whether multi-tasking has started yet or not and
either return the task executing element or return the _GLOBAL_REENT
for the time before.
I am wondering what other side effects there will be and whether this
is better than defining CONFIGURE_DISABLE_NEWLIB_REENTRANCY. I might
try an experiment to check which method might be better for us.
If you update to the current master
https://git.rtems.org/rtems/commit/?id=d1f7204649ff7c8bed36eab5af20c1a108af8b14
then you could try to add this to the module which contains your
application configuration:
#define CONFIGURE_DISABLE_NEWLIB_REENTRANCY
struct _reent *__getreent(void)
{
Thread_Control *executing;
executing = _Thread_Get_executing();
if (executing != NULL) {
return executing->libc_reent;
} else {
return _GLOBAL_REENT;
}
}
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
