Use mmap(), not malloc(), in vfprintf (XCC)
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 1 Jul 2016 18:51:18 +0000 (14:51 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 7 Jul 2016 16:39:01 +0000 (12:39 -0400)
commita9967a049a826989952d8976fda332f015c8e45a
tree903f7f1b62e3761a6b209e72d120af2b3bd5bbe0
parentbcab4ec6bf0a1c8621542870a2a4e788ae866c74
Use mmap(), not malloc(), in vfprintf (XCC)

Using malloc created an ordering between any of the printf calls and
malloc.  If malloc itself did anything that called back into printf, such
as a diagnostic warning, a SIGSEGV (which leads to printing), an snprintf
to talk to a kernel device, etc, then malloc would be calling itself.  That
could trigger a deadlock, depending on what malloc does internally.

By relying on mmap() only, we limit the amount of code that printf depends
on.  Note that if you ever put a printf in glibc's mmap() stub, you might
have issues.  Imagine a generic printf call: grabs glibc's IO lock, mmaps,
tries to print, then deadlocks on the *IO lock*.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/vfprintf.c