[PATCH] Introduce _REENT_GLOBAL_STDIO_STREAMS
In Newlib, the stdio streams are defined to thread-specific pointers
_reent::_stdin, _reent::_stdout and _reent::_stderr. In case
_REENT_SMALL is not defined, then these pointers are initialized via
_REENT_INIT_PTR() or _REENT_INIT_PTR_ZEROED() to thread-specific FILE
objects provided via _reent::__sf[3]. There are two problems with this
(at least in case of RTEMS).
(1) The thread-specific FILE objects are closed by _reclaim_reent().
This leads to problems with language run-time libraries that provide
wrappers to the C/POSIX stdio streams (e.g. C++ and Ada), since they
use the thread-specific FILE objects of the initialization thread. In
case the initialization thread is deleted, then they use freed memory.
(2) Since thread-specific FILE objects are used with a common output
device via file descriptors 0, 1 and 2, the locking at FILE object level
cannot ensure atomicity of the output, e.g. a call to printf().
Introduce a new Newlib configuration option _REENT_GLOBAL_STDIO_STREAMS
to enable the use of global stdio FILE objects. Use this option for RTEMS.
Signed-off-by: Sebastian Huber
---
newlib/libc/include/sys/config.h | 1 +
newlib/libc/include/sys/reent.h | 21 +++--
newlib/libc/stdio/findfp.c | 6 ++
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/newlib/libc/include/sys/config.h b/newlib/libc/include/sys/config.h
index 555239f8b..ae8caff7b 100644
--- a/newlib/libc/include/sys/config.h
+++ b/newlib/libc/include/sys/config.h
@@ -238,6 +238,7 @@
#define _READ_WRITE_RETURN_TYPE _ssize_t
#define __DYNAMIC_REENT__
#define _REENT_GLOBAL_ATEXIT
+#define _REENT_GLOBAL_STDIO_STREAMS
#endif
#ifndef __EXPORT
diff --git a/newlib/libc/include/sys/reent.h b/newlib/libc/include/sys/reent.h
index 8b67889ac..2a79ccc71 100644
--- a/newlib/libc/include/sys/reent.h
+++ b/newlib/libc/include/sys/reent.h
@@ -644,14 +644,23 @@ struct _reent
of the above members (on the off chance that future binary compatibility
would be broken otherwise). */
struct _glue __sglue;/* root of glue chain */
+# ifndef _REENT_GLOBAL_STDIO_STREAMS
__FILE __sf[3]; /* first three file descriptors */
+# endif
};
+#ifdef _REENT_GLOBAL_STDIO_STREAMS
+extern __FILE __sf[3];
+#define _REENT_STDIO_STREAM(var, index) &__sf[index]
+#else
+#define _REENT_STDIO_STREAM(var, index) &(var).__sf[index]
+#endif
+
#define _REENT_INIT(var) \
{ 0, \
-&(var).__sf[0], \
-&(var).__sf[1], \
-&(var).__sf[2], \
+_REENT_STDIO_STREAM(var, 0), \
+_REENT_STDIO_STREAM(var, 1), \
+_REENT_STDIO_STREAM(var, 2), \
0, \
"", \
0, \
@@ -696,9 +705,9 @@ struct _reent
}
#define _REENT_INIT_PTR_ZEROED(var) \
- { (var)->_stdin = &(var)->__sf[0]; \
-(var)->_stdout = &(var)->__sf[1]; \
-(var)->_stderr = &(var)->__sf[2]; \
+ { (var)->_stdin = _REENT_STDIO_STREAM(var, 0); \
+(var)->_stdout = _REENT_STDIO_STREAM(var, 1); \
+(var)->_stderr = _REENT_STDIO_STREAM(var, 2); \
(var)->_new._reent._rand_next = 1; \
(var)->_new._reent._r48._seed[0] = _RAND48_SEED_0; \
(var)->_new._reent._r48._seed[1] = _RAND48_SEED_1; \
diff --git a/newlib/libc/stdio/findfp.c b/newlib/libc/stdio/findfp.c
index 83d3dc558..886ca7cc6 100644
--- a/newlib/libc/stdio/findfp.c
+++ b/newlib/libc/stdio/findfp.c
@@ -35,6 +35,10 @@ const struct __sFILE_fake __sf_fake_stderr =
{_NULL, 0, 0, 0, 0, {_NULL, 0}, 0, _NULL};
#endif
+#ifdef _REENT_GLOBAL_STDIO_STREAMS
+__FILE __sf[3];
+#endif
+
#if (defined (__OPTIMIZE_SIZE__) || defined (PREFER_SIZE_OVER_SPEED))
_NOINLINE_STATIC _VOID
#else
@@ -221,8 +225,10 @@ _DEFUN(__sinit, (s),
s->__sglue._next = NULL;
#ifndef _REENT_SMALL
+# ifndef _REENT_GLOBAL_STDIO_STREAMS
s->__sglue._niobs = 3;
s->__sglue._iobs = &s->__sf[0];
+# endif
#else
s->__sglue._niobs = 0;
s->__sglue._iobs = NULL;
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Introduce _REENT_GLOBAL_STDIO_STREAMS
The per-thread memory reduction is noticeable: (gdb) p sizeof(struct _reent) $1 = 344 (gdb) p sizeof(__sf) $2 = 384 (gdb) So, struct _reent is more than 50% smaller. -- 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Introduce _REENT_GLOBAL_STDIO_STREAMS
Submit to newlib ml. It looks like a reasonable thing to do if the newlib general maintainers agree with the use of the new option. On Thu, Jun 22, 2017 at 4:11 AM, Sebastian Huber wrote: > The per-thread memory reduction is noticeable: > > (gdb) p sizeof(struct _reent) > $1 = 344 > (gdb) p sizeof(__sf) > $2 = 384 > (gdb) > > So, struct _reent is more than 50% smaller. > > -- > 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. > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/10] top/task1.c: Fix sprintf() buffer overflow
On Wed, Jun 21, 2017 at 1:52 PM, Joel Sherrill wrote:
> ---
> testsuites/libtests/top/task1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/testsuites/libtests/top/task1.c b/testsuites/libtests/top/task1.c
> index fc81f51..c9e62df 100644
> --- a/testsuites/libtests/top/task1.c
> +++ b/testsuites/libtests/top/task1.c
> @@ -28,7 +28,7 @@ static void create_and_start( uint32_t i )
> {
>rtems_status_code status;
>char str[30];
> - char name[5];
> + char name[6];
>
>sprintf(name, "TA%02" PRId32 " ", i);
Do you know that i < 10?
>
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 02/10] top/task1.c: Fix sprintf() buffer overflow
On Thu, Jun 22, 2017 at 10:53 AM, Gedare Bloom wrote:
> On Wed, Jun 21, 2017 at 1:52 PM, Joel Sherrill wrote:
>> ---
>> testsuites/libtests/top/task1.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/testsuites/libtests/top/task1.c
>> b/testsuites/libtests/top/task1.c
>> index fc81f51..c9e62df 100644
>> --- a/testsuites/libtests/top/task1.c
>> +++ b/testsuites/libtests/top/task1.c
>> @@ -28,7 +28,7 @@ static void create_and_start( uint32_t i )
>> {
>>rtems_status_code status;
>>char str[30];
>> - char name[5];
>> + char name[6];
>>
>>sprintf(name, "TA%02" PRId32 " ", i);
>
> Do you know that i < 10?
Nevermind, I misread this. Looks good.
>
>>
>> --
>> 1.8.3.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Introduce _REENT_GLOBAL_STDIO_STREAMS
On Thu, Jun 22, 2017 at 9:52 AM, Gedare Bloom wrote: > Submit to newlib ml. It looks like a reasonable thing to do if the > newlib general maintainers agree with the use of the new option. > +1 This certainly should correct the odd behavior that people have seen. > > On Thu, Jun 22, 2017 at 4:11 AM, Sebastian Huber > wrote: > > The per-thread memory reduction is noticeable: > > > > (gdb) p sizeof(struct _reent) > > $1 = 344 > > (gdb) p sizeof(__sf) > > $2 = 384 > > (gdb) > > > > So, struct _reent is more than 50% smaller. > > > > -- > > 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. > > > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RISC-V/HiFive memory limitations
> > Ok, then I will try to adapt the default linkcmd file today. > > -- > Regards, Denis Obrezkov > Hello all, It seems that data section wasn't copied from ROM, so I've added the initialization code and now I have a proper value. Thus, I can proceed further to new errors. I haven't started to develop new linkcmd file, general for the architecture + specific for the BSP. Should I? Hesham? Also, I have a question: there is a section called 'rwbarrier' and it is placed in data. Should it be also initialized? (copied from rom) And is it possible to decrease a required memory amount by restricting a user to C language usage? (no C++ sections in linkcmd) -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS-libbsd trailing whitespace
Hi Sebastian, When i import file from freebsd-org by using ./freebsd-to-rtems.py -R && ./freebsd-to-rtems.py, these files seems has many trailing whitespace. When i try to create the patch then apply it, there are many warning. So should i remove these trailing whitespace handly or just leave it. Best Regards Sichen Zhao ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GDB 8.0 build on FreeBSD 11
On 21/06/2017 16:05, Sebastian Huber wrote: > Hello, > > I tried to build GDB 8.0 on FreeBSD 11. It didn't work similar to: > > https://sourceware.org/ml/gdb/2017-02/msg00061.html > > The corresponding bug was resolved as invalid: > > https://sourceware.org/bugzilla/show_bug.cgi?id=21206 > > We still have a GDB patch for this issue in the RSB for 7.12. Now I am a bit > confused. > The problem is gnulib being configured with a C compiler and GDB is built with C++. The C compiler is missing something C++ has so we get a clash. The problem is in FreeBSD and not in gdb. John Baldwin provided a work around which is what we are using. The ticket shows the changes in FreeBSD fix the problem. I suspect in time this patch will become specific to FreeBSD version 11.0 and earlier. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GDB 8.0 build on FreeBSD 11
On 23/06/17 06:37, Chris Johns wrote: I suspect in time this patch will become specific to FreeBSD version 11.0 and earlier. Ok, thanks for clarification. -- 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
