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?

                Thanks,
                -Dave

(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> mips.com

2014-10-02  Steve Ellcey  <sellcey <at> mips.com>

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

diff --git a/newlib/libc/machine/mips/Makefile.am b/newlib/libc/machine/mips/Makefile.am
index 46b4cc3..1695b18 100644
--- a/newlib/libc/machine/mips/Makefile.am
+++ b/newlib/libc/machine/mips/Makefile.am
 <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.com
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: http://www.ezysoft.in/ocjnvzulsx/begmnbjiae.html

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.

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

[1] http://www.mail-archive.com/mspgcc-users <at> lists.sourceforge.net/msg12104.html

Cc: dj <at> redhat.com
Cc: nickc <at> redhat.com
Signed-off-by: Peter A. Bigot <pab <at> pabigot.com>
---
 libgloss/configure            |  1 -
 libgloss/configure.in         |  1 -
 libgloss/msp430/Makefile.in   | 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
Picon

[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.

newlib/ChangeLog
2014-09-22  Sebastian Huber  <sebastian.huber <at> embedded-brains.de>

	* libc/include/inttypes.h: Add and
	use __INTTYPES_HAVE_LONGLONG64, __INTTYPES_HAVE_LONG64 and
	__INTTYPES_HAVE_LONG32.
---
 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>
 #endif

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

Jeff Johnston | 20 Sep 04:15 2014
Picon

On Vacation

Just to let everyone know, I will be away on vacation until Oct. 4th.
Unfortunately, Corinna is also on vacation until Oct 8th so don't expect
responses from either of us until then.

Regards,

-- Jeff J.

Jonathan Roelofs | 20 Sep 00:40 2014

[PATCH] Update newlib so that it passes libc++'s tests

(For context, here's the original thread: 
https://sourceware.org/ml/newlib/2013/msg01077.html)

I've rebased the remaining part of the original patch.  Please see the attached. 
Is this good for commit, or does it still need work?

Cheers,
Jon

-- 
Jon Roelofs
jonathan <at> codesourcery.com
CodeSourcery / Mentor Embedded
diff --git a/src/newlib/libc/include/stdlib.h b/src/newlib/libc/include/stdlib.h
index dee9ed6..374b9b6 100644
--- a/src/newlib/libc/include/stdlib.h
+++ b/src/newlib/libc/include/stdlib.h
 <at>  <at>  -151,7 +151,12  <at>  <at>  long    _EXFUN(a64l,(const char *__input));
 char *  _EXFUN(l64a,(long __input));
 char *  _EXFUN(_l64a_r,(struct _reent *,long __input));
 int	_EXFUN(on_exit,(_VOID (*__func)(int, _PTR),_PTR __arg));
+#endif
+#if !defined(__STRICT_ANSI__) || \
+  (defined(__STDC_VERSION__) || __STDC_VERSION__ >= 199901L) || \
+  (defined(__cplusplus) && __cplusplus >= 201103L)
 _VOID	_EXFUN(_Exit,(int __status) _ATTRIBUTE ((__noreturn__)));
+#ifndef __STRICT_ANSI__
 int	_EXFUN(putenv,(char *__string));
(Continue reading)

Joel Sherrill | 18 Sep 22:58 2014

inttypes. uintptr_t patch v1

Hi

Attached is a first cut at the changes we discussed last week
to determine if uintptr_t is unsigned long long, unsigned long,
or simply unsigned int (default).

I haven't tested this extensively and am a bit concerned that
on the m68k uintptr_t is typedef'ed to "unsigned int" but the
probe detects it as "unsigned long". I haven't gotten far enough
to see if this makes the printf() checking happy with my test
case but wanted feedback.

I will need to build a bunch of toolsets to test this properly and
would rather get feedback before I invest a lot of time in this.

Thanks.

2014-09-18  Joel Sherrill <joel.sherrill>

        * configure.in: Add probes to determine if uintptr_t is
        unsigned long (define _UINTPTR_EQ_ULONG) or unsigned long long
        (define _UINTPTR_EQ_ULONGLONG).
        * configure: Regenerated.
        * newlib.him: Add new probe macros.
        * libc/include/inttypes.h: Use new probe macros.

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill <at> OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
(Continue reading)

Jonathan Roelofs | 17 Sep 23:09 2014

_NEWLIB_VERSION exposure through sys/cdefs.h

Corinna,

In libc++, we'd like to be able to tell when the underlying libc is Newlib. At 
the moment, that requires us to do things like this:

#if defined(__has_include) && __has_include(<newlib.h>)
#include <newlib.h>
#endif
#if defined(_NEWLIB_VERSION)
...
#endif

The problem with that strategy is that it does not work when using gcc, as it 
doesn't have __has_include support yet.  It came up in discussion that 
sys/cdefs.h might be the right place for that, as that's where glibc puts __GLIBC__.

Would there be an objection to #include <newlib.h> from sys/cdefs.h?  Is there a 
better way to detect Newlib that I've overlooked?

Cheers,

Jon

--

-- 
Jon Roelofs
jonathan <at> codesourcery.com
CodeSourcery / Mentor Embedded

Joel Sherrill | 17 Sep 18:34 2014

Preferred autoconf version and question

Hi

What's the preferred autoconf version? I installed 2.59
since that was the version listed in the top level
configure.in but during autoreconf, it said >= 2.62. I had
2.64 installed and it ended up running a long time,
complaining a lot, and regenerating a lot of files.

I was using a simple "autoreconf" from the newlib
directory.

Just wanting to start trying to add the probe for inttypes.h
we discussed. But have to be able to regenerate the
autotools files first. :)

Thanks.

--

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill <at> OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


Gmane