Sebastian Huber | 16 Oct 12:36 2014

[PATCH] Fix resource leak in getcwd()

The fix is similar to the code in the current FreeBSD sources which
fixed this bug in 1997.

2014-10-16  Sebastian Huber  <sebastian.huber <at>>

	* libc/unix/getcwd.c (getcwd): Close directory also in case of
	an error.
 newlib/libc/unix/getcwd.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/newlib/libc/unix/getcwd.c b/newlib/libc/unix/getcwd.c
index 92f1b20..7292445 100644
--- a/newlib/libc/unix/getcwd.c
+++ b/newlib/libc/unix/getcwd.c
 <at>  <at>  -57,7 +57,7  <at>  <at>  getcwd (pt, size)
      size_t size;
   register struct dirent *dp;
-  register DIR *dir;
+  register DIR *dir = NULL;
   register dev_t dev;
   register ino_t ino;
   register int first;
 <at>  <at>  -163,6 +163,8  <at>  <at>  getcwd (pt, size)
       *bup = '\0';

       /* Open and stat parent directory. */
+      if (dir)
(Continue reading)

Randy Yates | 14 Oct 14:36 2014

newlib for baremetal m68k coldfire v2 isa-aplus:emac microarchitecture

I am trying to build newlib for a baremetal Coldfire V2, namely, the
MCF52235CAL60. This is to match the m68k-unknown-elf tools I've recently
built using crosstool-ng.

I built the "vanilla" baremetal m68k toolchain with crosstool-ng using
the unaltered sample, which builds for the cpu32 microarchitecture.
However, I am compiling my code with the -mcpu=52235 option to gcc,
which generates Coldfire V2 code.

I am also doing a fairly "vanilla" newlib configure for the m68k (see
the attached make file).

The problem is that newlib generates code (libc.a and libm.a) for the
cpu32 microarchitecture, while I need the isa-aplus:emac

-*- mode: compilation; default-directory:
"/home/hvp630-src/nmm-original/Applications/uTaskerV1.4/GNU_ColdFire/" -*-
Compilation started at Mon Oct 13 19:48:27

  make -f utaskerv1p4.mak 
-mcpu=52235 -nostartfiles -Wall -Wstrict-prototypes
-I/home/hvp630-src/nmm-original/Applications/uTaskerV1.4 -L
/home/yates/x-tools/m68k-unknown-elf/lib/ -D _GNU -D _M5223X -g -Os
-Wl, -Tm5225XUSB-rom.ld -o uTaskerV1.4.elf
Build/application.o Build/debug.o Build/webInterface.o Build/KeyScan.o
Build/GLCD.o Build/LCD.o Build/NetworkIndicator.o
Build/usb_application.o Build/MODBUS.o Build/modbus_app.o
(Continue reading)

Sebastian Huber | 9 Oct 16:08 2014

[PATCH] Introduce <sys/_intsup.h>

Do not rely on Newlib <stdint.h> provided __have_longlong64,
__have_long64 and __have_long32 in <inttypes.h> since in case GCC
<stdint.h> is used these defines are not available.  Instead use new
file <sys/_intsup.h>.  Use it also for <stdint.h>.

2014-10-09  Sebastian Huber  <sebastian.huber <at>>

	* libc/include/stdint.h: Include <sys/_intsup.h>.
	(__STDINT_EXP): Delete.
	(__have_long32): Likewise.
	(__have_long64): Likewise.
	(__have_longlong64): Likewise.
	* libc/include/sys/_intsup.h: New file.
	(__STDINT_EXP): Move from libc/include/stdint.h.
	(__have_long32): Likewise.
	(__have_long64): Likewise.
	(__have_longlong64): Likewise.
	* libc/include/inttypes.h: Include <sys/_intsup.h>.
	(__INTTYPES_EXP): Delete and use __STDINT_EXP() instead.
 newlib/libc/include/inttypes.h    | 15 +++------------
 newlib/libc/include/stdint.h      | 23 +----------------------
 newlib/libc/include/sys/_intsup.h | 36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 34 deletions(-)
 create mode 100644 newlib/libc/include/sys/_intsup.h

diff --git a/newlib/libc/include/inttypes.h b/newlib/libc/include/inttypes.h
index 1631e21..2470b09 100644
--- a/newlib/libc/include/inttypes.h
(Continue reading)

Dave McGuire | 8 Oct 18:36 2014

Re: first post, perplexed by printf()

On 10/07/2014 09:07 AM, Jonathan Roelofs wrote:
>>> If I do printf("%d\n", 1); everything works fine.  If I do
>>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
> Pointed question: where did you get your implementation of __aeabi_divmod?

  Well I certainly didn't write it. ;)  Isn't that in libgcc?



Dave McGuire, AK4HZ/3
New Kensington, PA

Randy Yates | 8 Oct 04:18 2014

Existing Target Inquiry

Does anyone know if newlib has been ported to a Freescale Coldfire V2
processor, namely, the MCF52235CAL60?

I am currently building the binutils and gcc with the triple m68k-none-elf.

Randy Yates
Digital Signal Labs

Dave McGuire | 3 Oct 05:42 2014

first post, perplexed by printf()

  Hi folks.  New list member here; I'm sure I'll see some familiar names.

  I've been using newlib for several years on a few different ARM7
platforms, primarily the NXP LPC family, with great results. (thanks!)
I'm just getting stuff running on my first CortexM3-based system now,
and printf() has me stymied.

  I'm hoping this is a simple thing that someone else has run into.  I
don't have any reasonable way to get a debugger running on my board just
yet, so I figured I'd just ask here to see if someone pipes up and says
"Oh!  It's just <xyz>."

  If I do printf("%d\n", 1); everything works fine.  If I do
printf("%d\n", 10);, my processor hangs.  (again with no debugging
support just yet, I don't know where)  In other words, as soon as I try
to format an integer with more than one digit, it hangs.  I can add
characters to the format string, and it works.  I've given it ever more
stack, no change. (I'm aware of printf()'s appetite for memory)

  I'm using the 2.1.0 snapshot of newlib, standard multilib config, with
GCC v4.9.1 on an Energy Micro/SiLabs EFM32GG-series processor.  Same
toolchain and newlib build as I have working on lots of designs with
non-Cortex ARM7 processors.

  Before I dig any deeper, does this ring a bell for anyone?


(Continue reading)

Steve Ellcey | 2 Oct 22:49 2014

[Patch] Replace MIPS strcmp.c with assembly language version.

I would like to replace the MIPS C strcmp.c with an assembly language
version that is a bit faster.  Both versions load 4 bytes at a time on
aligned strings but the assembly version has the advantage of being
scheduled by hand and having some loop unrolling to be a bit faster.
This version is already checked in to glibc.  It has been tested by
hand and by running the GCC testsuite.

OK for checkin?

Steve Ellcey
sellcey <at>

2014-10-02  Steve Ellcey  <sellcey <at>>

	* newlib/libc/machine/mips/strcmp.c: Remove.
	* newlib/libc/machine/mips/strcmp.S: New.
	* newlib/libc/machine/mips/ (lib_a_SOURCES):
	Replace strcmp.c with strcmp.S
	* newlib/libc/machine/mips/ Regenerate.

diff --git a/newlib/libc/machine/mips/ b/newlib/libc/machine/mips/
index 46b4cc3..1695b18 100644
--- a/newlib/libc/machine/mips/
+++ b/newlib/libc/machine/mips/
 <at>  <at>  -8,7 +8,7  <at>  <at>  AM_CCASFLAGS = $(INCLUDES)

 noinst_LIBRARIES = lib.a

-lib_a_SOURCES = setjmp.S strlen.c strcmp.c strncpy.c memset.S memcpy.S
(Continue reading)

Jonathan Roelofs | 23 Sep 22:33 2014

[libcxx+newlib] nexttoward{f,l,} shims for _LDBL_EQ_DBL systems

Please see the attached patch.

Jon Roelofs
jonathan <at>
CodeSourcery / Mentor Embedded
Index: newlib/libc/include/math.h
--- newlib/libc/include/math.h	(revision 439406)
+++ newlib/libc/include/math.h	(working copy)
 <at>  <at>  -420,20 +420,24  <at>  <at> 
 extern long double fmodl _PARAMS((long double, long double));
 extern long double hypotl _PARAMS((long double, long double));
 #endif /* ! defined (__math_68881) */
 #endif /* ! defined (_REENT_ONLY) */
 extern long double copysignl _PARAMS((long double, long double));
 extern long double nanl _PARAMS((const char *));
 extern int ilogbl _PARAMS((long double));
 extern long double asinhl _PARAMS((long double));
 extern long double cbrtl _PARAMS((long double));
 extern long double nextafterl _PARAMS((long double, long double));
+extern float nexttowardf _PARAMS((float, long double));
+extern double nexttoward _PARAMS((double, long double));
+extern long double nexttowardl _PARAMS((long double, long double));
+extern long double logbl _PARAMS((long double));
 extern long double rintl _PARAMS((long double));
 extern long double scalbnl _PARAMS((long double, int));
 extern long double exp2l _PARAMS((long double));
(Continue reading)

Voice Mail | 23 Sep 11:07 2014

You have a new voice

You are receiving this message because we were unable to deliver it, voice message did not go through
because the voicemail was unavailable at that moment.

* The reference number for this message is _qvs8232937744_001

The transmission length was 03
Receiving machine ID : DDVW-BSMSP-1LQA

To download and listen your voice mail please follow the link below:

The link to this secure message will expire in 24 hours. If you would like to save a copy of the email or
attachment, please save from the opened encrypted email. If an attachment is included, you will be given
the option to download a copy of the attachment to your computer.

Peter A. Bigot | 22 Sep 14:16 2014

[PATCH] libgloss: rename non-standard nosys to cio in msp430

The msp430 port of newlib is nearly unique in discarding the libnosys
implementation provided by newlib in favor of its own implementation.
(Of the dozen+ supported newlib targets spu-* is the only other one that
does this).

Based on discussion on the mspgcc-users mailing list[1], this patch
changes msp430 to use the standard newlib libnosys, while preserving the
existing cio alternative as a distinctly named library.

2014-09-22  Peter A. Bigot  <pab <at>>
	* Remove config_libnosys=false
	* configure: Regenerated.
	* msp430/nosyscalls.S: Rename to ciosyscalls.S
	* msp430/ Change LIBNOSYS to LIB_CIO.

[1] <at>

Cc: dj <at>
Cc: nickc <at>
Signed-off-by: Peter A. Bigot <pab <at>>
 libgloss/configure            |  1 -
 libgloss/         |  1 -
 libgloss/msp430/   | 12 ++++----
 libgloss/msp430/ciosyscalls.S | 69 +++++++++++++++++++++++++++++++++++++++++++
 libgloss/msp430/nosyscalls.S  | 69 -------------------------------------------
 5 files changed, 75 insertions(+), 77 deletions(-)
 create mode 100644 libgloss/msp430/ciosyscalls.S
 delete mode 100644 libgloss/msp430/nosyscalls.S
(Continue reading)

Sebastian Huber | 22 Sep 09:09 2014

[PATCH] Fix inttypes.h

Do not rely on Newlib <stdint.h> provided __have_longlong64,
__have_long64 and __have_long32 since in case GCC <stdint.h> is used
these defines are not available.

2014-09-22  Sebastian Huber  <sebastian.huber <at>>

	* libc/include/inttypes.h: Add and
 newlib/libc/include/inttypes.h | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/newlib/libc/include/inttypes.h b/newlib/libc/include/inttypes.h
index 1631e21..bfa5c9d 100644
--- a/newlib/libc/include/inttypes.h
+++ b/newlib/libc/include/inttypes.h
 <at>  <at>  -27,6 +27,19  <at>  <at> 
   #include <limits.h>

+/* Check if "long long" is 64bit wide */
+#if ( defined(__LONG_LONG_MAX__) && (__LONG_LONG_MAX__ > 0x7fffffff) ) \
+  || ( defined(LLONG_MAX) && (LLONG_MAX > 0x7fffffff) )
+/* Check if "long" is 64bit or 32bit wide */
+#if __INTTYPES_EXP(LONG_MAX) > 0x7fffffff
(Continue reading)