Reduce stack usage of _vfiprintf_r()

Freddie Chopin freddie_chopin@op.pl
Tue Oct 16 18:56:00 GMT 2012


Hi!

How about the attached patch? I've tested and everything is fine. It's 
of course a modified version of patch from Corina, but with removed 
condition of size optimization.

Now each entry to _vfprintf_r() costs only about 190 bytes and 
__sbprintf() allocates about 1150 (on ARM Cortex-M3).

4\/3!!
-------------- next part --------------
From b8ab7caed0c4f12f8b824751a594f89515c4d9b3 Mon Sep 17 00:00:00 2001
From: Freddie Chopin <freddie.chopin@gmail.com>
Date: Fri, 12 Oct 2012 23:09:23 +0200
Subject: [PATCH] Prevent __sbprintf() from being inlined.

If __sbprintf() is inlined into _vfprintf_r() (it's static and used
only in this function) each entry to _vfprintf_r() would allocate a
huge buffer of BUFSIZ size (default 1024) on stack. This buffer is
only used when dealing with unbuffered stream - __sbprintf()
creates a fake buffered stream and calls _vfprintf_r() again. With
this patch the buffer is allocated only when actually using
unbuffered stream and only once (without it the recursive call to
_vfprintf_r() would allocate the buffer again).

See http://sourceware.org/ml/newlib/2012/msg00389.html for further
information.

Signed-off-by: Freddie Chopin <freddie.chopin@gmail.com>
---
 newlib/libc/stdio/vfprintf.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/newlib/libc/stdio/vfprintf.c b/newlib/libc/stdio/vfprintf.c
index 4b165e0..55d6e25 100644
--- a/newlib/libc/stdio/vfprintf.c
+++ b/newlib/libc/stdio/vfprintf.c
@@ -334,7 +334,10 @@ int __sprint_r (struct _reent *, FILE *, register struct __suio *);
  * temporary buffer.  We only work on write-only files; this avoids
  * worries about ungetc buffers and so forth.
  */
-static int
+#if defined (__GNUC__) && __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
+__attribute__ ((__noinline__)) static
+#endif
+int
 _DEFUN(__sbprintf, (rptr, fp, fmt, ap),
        struct _reent *rptr _AND
        register FILE *fp   _AND
-- 
1.7.12.2



More information about the Newlib mailing list