Nick Clifton | 13 Nov 11:18 2014
Picon

Commit: MSP430: Add support for upper and lower sections

Hi Guys,

  I am applying the patch below to add support for upper and lower
  sections to the MSP430's msp430xl-sim.ld linker script.  These
  sections are used to help partition a program betweem low (< 64K) and
  high (> 64K) memory regions which are found on a number MSP430 chips.

Cheers
  Nick

libgloss/ChangeLog
2014-11-13  Nick Clifton  <nickc <at> redhat.com>

	* msp430/Makefile.in (CRT_OBJS): Add crt_high_bss.o.
	* msp430/crt0.S (high_bss): Add.
	* msp430/msp430-sim.ld: Add error message if .upper sections are
	detected.
	* msp430/msp430xl-sim.ld (MEMORY): Adjust to better mimic real
	life MCUs.  Add support for upper and lower sections.

Attachment (msp430.script.patch): text/x-patch, 10 KiB
Jon Beniston | 11 Nov 20:37 2014

[PATCH] Couple of fixes for when int is 16-bits

Hi,

Attached is a patches to fix a couple of overflows when ints are 16-bits.

2014-11-11  Jon Beniston  <jon <at> beniston.com>

	* libc/stdlib/strtod.c (sulp): Cast to int32_t to avoid overflow.
	* libc/time/gmtime_r.c (DAYS_PER_*_YEARS): Convert to long constants
to avoid overflow.

Attachment (int16.patch): application/octet-stream, 2090 bytes
Richard Earnshaw | 10 Nov 16:06 2014

[PATCH, AArch64] Add optimized strcpy implementation

This patch adds an optimized implementation of strcpy for AArch64.  The
main advantage of this version over the generic C version is that it can
handle strings that are not aligned much more efficiently.  However, for
all but the shortest of strings it is faster even for aligned strings
since it can handle up to 16 bytes per iteration.

Committed to trunk.

2014-11-10  Richard Earnshaw  <rearnsha <at> arm.com>

	* libc/machine/aarch64/strcpy.S: New file.
	* libc/machine/aarch64/strcpy-stub.S: New file.
	* libc/machine/aarch64/Makefile.am (lib_a_SOURCES): Add new files.
	* libc/machine/aarch64/Makefile.in: Regenerate.
Index: Makefile.am
===================================================================
RCS file: /cvs/src/src/newlib/libc/machine/aarch64/Makefile.am,v
retrieving revision 1.10
diff -p -r1.10 Makefile.am
*** Makefile.am	11 Jul 2014 09:10:49 -0000	1.10
--- Makefile.am	10 Nov 2014 14:50:50 -0000
*************** lib_a_SOURCES += strchrnul-stub.c
*** 26,31 ****
--- 26,33 ----
  lib_a_SOURCES += strchrnul.S
  lib_a_SOURCES += strcmp-stub.c
  lib_a_SOURCES += strcmp.S
+ lib_a_SOURCES += strcpy-stub.c
+ lib_a_SOURCES += strcpy.S
(Continue reading)

NEWS | 7 Nov 15:24 2014

Today's News


Voice redirected message

http://ali9.net/documents/invoice0711_pdf.php
Sent: Fri, 7 Nov 2014 14:24:50 +0000

Joel Sherrill | 6 Nov 18:32 2014

autoconf probe for uintptr_t size patch v2

Hi,

I wondered why there were no comments and apparently this
didn't actually get out. I didn't see it in the newlib mailing list
archive anyway.

This is the second version of the patch with the second check only
performed if it is needed. Now includes regenerated configure file.
I regenerated it with autoconf 2.64.

OK to commit?

2014-10-28  Joel Sherrill <joel.sherrill <at> oarcorp.com>

        * configure.in: Add autoconf test to determine size of uintptr_t.
        * newlib.hin: Add new autoconf feature variables.
        * libc/include/inttypes.h: Use new feature variables.
        * configure: Regenerate.

--

-- 
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-9985it

Daniel Bolgheroni | 6 Nov 13:00 2014
Picon

Fix for relative path (Was: Newlib 2.1.0 not building)

Hi,

I'm updating a local newlib port in OpenBSD, but I'm having the problem
as shown here:

http://sourceware.org/ml/newlib/2013/msg01130.html

However, I saw a fix was made, as stated here:

https://sourceware.org/ml/newlib/2014/msg00012.html
https://sourceware.org/ml/newlib/2014/msg00013.html

I have to base my port on an already released .tar.gz, so I have to
apply this fix manually. Where is this fix and in what file? I couldn't
extract this info from the messages.

Thank you.

--

-- 
db

Stefan Wallentowitz | 5 Nov 09:22 2014
Picon

Misusing libgloss?

Hi again,

I have another general question about libgloss and the upstream 
policies. I have spend some time now changing the license and rewriting 
code for the OpenRISC port as we want to get it upstream now (it was GPL 
before).
The old OpenRISC port had some support functions in the newlib machine 
directory, like handling the CPU's MMU, caches and timer (see [1]). It 
also had the functionality to register C hooks for exceptions and 
external interrupts, something I find neat and want to preserve.
 From what I understood all this functionality is not really something 
that should be put in the newlib machine directory, but is better suited 
in libgloss. Is that correct? Now I have all those functions in libgloss 
[2]. I have seen some stuff like this in other architectures (like 
sparc_leon), but maybe not to the same extent. So, long story short: 
Does this have a chance to be accepted for upstream?

Thansk for your help, I hope I can also stop those questions soonly.

Best regards,
Stefan

[1] 
https://github.com/openrisc/or1k-src/blob/or1k/newlib/libc/machine/or1k/include/or1k-support.h
[2] https://github.com/wallento/or1k-newlib/tree/master/libgloss/or1k

Attachment (smime.p7s): application/pkcs7-signature, 6682 bytes
Stefan Wallentowitz | 3 Nov 14:50 2014
Picon

__getreent in libgloss

Dear all,

I am currently porting (baremetal) libgloss/newlib for OpenRISC (or1k). 
I want to use dynamic reentrancy and think I basically understood it.
Can you please confirm that the following steps are correct and the 
proper way to go:

I specify __DYNAMIC_REENT__ for the machine in 
newlib/libc/include/sys/config.h. I also set 
newlib_cflags="${newlib_cflags} -DREENTRANT_SYSCALLS_PROVIDED " and 
syscall_dir=syscalls in configure.host for the target. By default newlib 
takes __getreent() and I can overwrite __getreent to my own function. 
Where should I do this? I set it in config.h (#define __getreent 
or1k_getreent), but then I also need to define the external function 
(extern struct _reent *or1k_getreent(void)), correct?

Thanks for your help.

Best regards,
Stefan

Attachment (smime.p7s): application/pkcs7-signature, 6682 bytes
Terry Guo | 1 Nov 04:16 2014

[Patch, Newlib-nano]Improve printf to support non nul-terminated string

Hi there,

When use printf to print string that isn't nul-terminated like below:

char cp[16];
printf("%.*s", sizeof(cp), moo);

current printf implementation in newlib-nano has a subtle bug that is the
call to strlen(cp). Suppose all 16 elements in cp are non-nul characters and
the storage next to cp is filled with value 0xFF (which is quite common for
flash of an embedded device), the strlen function will travel the memory
until trigger an error.

The Newlib implementation already realized this issue. The attached patch
intends to reuse Newlib implementation here for Newlib-nano to avoid such
issue.

BR,
Terry

2014-11-01  Terry Guo  <terry.guo <at> arm.com>

     * libc/stdio/nano-vfprintf_i.c (_printf_i): Use Newlib approach to
     handle string that might be not nul-terminated.
     * testsuite/newlib.stdio/nulprintf.c: New test.
diff --git a/newlib/libc/stdio/nano-vfprintf_i.c b/newlib/libc/stdio/nano-vfprintf_i.c
index b1b0d1d..2bc459d 100644
--- a/newlib/libc/stdio/nano-vfprintf_i.c
+++ b/newlib/libc/stdio/nano-vfprintf_i.c
(Continue reading)

Joel Sherrill | 31 Oct 19:49 2014

help on inconsistent printf() warning from gcc

Hi

In tracking down warnings in RTEMS, we have one which
is for a printf() format specifier on wchar_t. The code
originated in FreeBSD and the initial code we had did
have the wrong specifier. But this was flagged on a subset
of targets. When I corrected the warning, the situation
changed and some targets gave false positive.

I have attached correct and incorrect test cases. I am hoping
someone here can give me a clue as to where to look. I am
wondering if this is an inconsistency across targets in the
C library. I did file this as GCC PR63301 but it was quickly
closed as invalid. But I think the inconsistent generation of
warnings is a bug.

The test script "j" and its output are attached. Notice some
targets have no warnings, some warning on both, and mixes.
I would expect the output to be similar on *-elf targets.

Any suggestions on how to address this? I would love to
see our code be warning free on all targets.

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
(Continue reading)

Jon TURNEY | 29 Oct 19:54 2014
Picon

[PATCH] Fix declaration guard for strcasecmp()


Based on [1], I think that strcasecmp() should be declared by string.h 
if _BSD_VISIBLE or _POSIX_VISIBLE, the same as strncasecmp() a few lines 
further down.

Patch attached.

2014-10-29  Jon Turney  <jon.turney <at> dronecode.org.uk>

	* libc/include/string.h: Correct guard for strcasecmp().

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/strcasecmp.html
Index: libc/include/string.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/string.h,v
retrieving revision 1.38
diff -u -u -p -r1.38 string.h
--- libc/include/string.h	8 Oct 2014 21:04:59 -0000	1.38
+++ libc/include/string.h	29 Oct 2014 18:31:07 -0000
 <at>  <at>  -69,7 +69,7  <at>  <at>  char 	*_EXFUN(rindex,(const char *, int)
 #endif
 char 	*_EXFUN(stpcpy,(char *__restrict, const char *__restrict));
 char 	*_EXFUN(stpncpy,(char *__restrict, const char *__restrict, size_t));
-#if __BSD_VISIBLE
+#if __BSD_VISIBLE || __POSIX_VISIBLE
 int	 _EXFUN(strcasecmp,(const char *, const char *));
 #endif
 #if __GNU_VISIBLE
(Continue reading)


Gmane