Stefan Wallentowitz | 17 May 16:53 2015

[PATCH 1/8] or1k: Callee-saved registers for permanent data

Hi all,

this is the first of a set of patches for the or1k libgloss, essentially
some small bug fixes.

Thanks in advance!


During interrupt handling the PICSR, table pointers and current
interrupt line have been saved in incorrect registers and/or stored on
the stack.

Save the pointer in r16/r18, PICSR in r20 and the current interrupt
line in r22. Those are callee-saved registers, so that the register
values will be preserved.

    * or1k/interruts-asm.S: Change registers to callee-saved

Nick Clifton | 13 May 16:22 2015

RFA: RL78: Add an assertion to detect link time data overflow.

Hi DJ,

  The patch below adds an assertion the .stack sections in the RL78
  linker scripts in libgloss.  This assertion checks for the data area
  overflowing into the stack space.  (Using the linker's
  --check-sections option does not work because the .stack section is

  OK to apply ?


2015-05-13  Nick Clifton  <nickc <at>>

	* rl78/rl78.ld (.stack): Add an assertion to make sure that the
	data area does not overrun the stack.
	* rl78/rl78-sim.ld (.stack): Likewise.

diff --git a/libgloss/rl78/rl78-sim.ld b/libgloss/rl78/rl78-sim.ld
index 26d62ac..ff7f403 100644
--- a/libgloss/rl78/rl78-sim.ld
+++ b/libgloss/rl78/rl78-sim.ld
 <at>  <at>  -126,6 +126,10  <at>  <at>  SECTIONS
     PROVIDE (__stack = .);
+    /* Linker section checking ignores empty sections
+       like this so we have to have our own test here.
(Continue reading)

Nick Clifton | 12 May 12:05 2015

RFA: Fix signbit() for 16-bit targets

Hi Jeff, Hi Corinna,

  The signbit() functions in s_signbit.c are broken for targets that use
  16-bit integers.  Firstly the GET_*_WORD macros expect to place their
  result into a __uint32_t type, but they are being given an int type.
  Secondly the result of the functions is an int, so just extracting the
  sign bit via a mask is insufficient, as the result will be truncated
  to 16-bits.

  The patch below takes care of these problems.  Tested with no
  regressions on an rl78-elf toolchain.

  OK to apply ?


2015-05-12  Nick Clifton  <nickc <at>>

	* libm/common/s_signbit.c (__signbitf): Fix for 16-bit targets.
	(__signbitd): Likewise.

diff --git a/newlib/libm/common/s_signbit.c b/newlib/libm/common/s_signbit.c
index 746ab46..6ea714d 100644
--- a/newlib/libm/common/s_signbit.c
+++ b/newlib/libm/common/s_signbit.c
 <at>  <at>  -41,19 +41,19  <at>  <at>  int __signbitd (double x);
 __signbitf (float x)
(Continue reading)

Schwarz, Konrad | 11 May 09:23 2015

Proper way of replacing crt0.o/GCC search path for startup files


I have written an alternative crt0.o (the startup file placed at the
beginning of the executable) for a bare-metal system.

For GCC to use this, it requires a new specs file.

I would like to keep both the new specs file and the alternative crt0.o
in a central location, but not in GCC installation directories.

I was unable to find precise documentation on how GCC searches for specs
files and for startup files.  It seems like directories added by -L are
not searched for spec or startup files, for example.  (I.e., my_crt0%o%s was not
found by GCC, despite an appropriate -L argument).

My current solution uses an environment variable to point to the
directory containing the spec file and the my_crt0.o file.
This environment variable is expanded in the makefile to find the spec file
and is expanded in the spec file, via the %:getenv() spec-file function,
to find my_crt0.o.

This has the drawback of hard coding the name of this environment variable 
in the spec file.  Hence, the environment variable needs to be documented;
and impinges on the user's namespace of environment variables.

Is there a better way of doing this?  E.g., an option specifying additional
directories to look for spec and startup files?

(Although this is strictly a GCC question, libgloss contains numerous
spec files, so I am hoping to find some expertise here.)
(Continue reading)

David Stacey | 10 May 23:01 2015

[PATCH] Potential memory leak in argz_replace.c

I'm new to this list, so allow me to introduce myself. I am Dave Stacey, 
and I maintain a handful of packages for Cygwin. I also run a regular 
scan of the Cygwin source code using the Coverity Scan static analysis 
tool. I'd like to report a few warnings that Coverity reports in 
Cygwin's use of newlib. I'll start with one that's fairly simple; once 
I've learnt how you like these reporting then I'll try to send more.

The first is a theoretical (albeit unlikely) memory leak in 
argz_replace.c that occurs in the event that a realloc(3) fails. The 
attached patch should address this, and a ChangeLog entry is below. The 
change is rather trivial.

I'm aware that you need to support a great many compilers and platforms, 
and so I will completely understand if you would prefer to keep the code 
as it is. Hopefully the patch is in keeping with the style of the 
surrounding code, but if you would like anything altered then let me 
know and I will do my best to oblige.


Dave Stacey.

2015-05-10  David Stacey  <drstacey <at>>

     * libc/argz/argz_replace.c: Fix potential memory leak.

--- a/newlib/libc/argz/argz_replace.c	2015-03-10 10:40:06.000000000 +0000
(Continue reading)

Junfeng Dong | 6 May 02:20 2015

can newlib really work as linux C library on i686 or x86_64?

Recently I tried to use newlib to build simple programs on x86_64 or
i686. I run into various problems.Can someone please tell me what is
the mistake I made.
1. when build it as part of cross toolchain (target is i686-linux-elf,
host is x86_64). it shows crt0.o is missing.
2. native build with "-with-newlib --disable-multilib" on i686
machine. it failed with
/usr/include/i386-linux-gnu/bits/types.h:170:1: error: unknown type
name ‘__FSWORD_T_TYPE’

I searched the history mailing list. It is said that "Newlib is almost
NEVER built as a linux library. That it can do so AT ALL is a recent
change and rarely used" "Newlib is intended for bare-metal targets
like m32c-elf, arm-elf, h8300-coff, etc."
Have things changed from that? Can newlib really work as linux C
library on i686 and fully tested?

Best regards

Roberto Martelloni | 5 May 16:01 2015

question about security issues affecting newlib


how can I know when a software vulnerability affecting newlib has been
detected, reported and fixed ?

Since in my understanding newlib is a conglomerate of different source code
plus obviously custom source code:

   - what would be an a reasonable way to ensure that my newlib version XXX
   is free from know vulnerabilities ?

Or from a different point of view, how do you ensure that newlib is not
including a known vulnerability/ies ? How do you deal with that ?

Many Thanks,

P.S. put be in CC as I'm not subscribed to the maillist, many thanks


Roberto Martelloni
boos  <at>

Nick Clifton | 5 May 13:44 2015

Commit: MSP430: Add support for low & high sections

Hi Guys,

  This patch supports an about-to-be-contributed patch to GCC for the
  MSP430 will add the ability for the compiler and linker to dynamically
  allocate data and code to either a low (<64K) memory region or a high
  memory region.  In order for this feature to work the MSP430 linker
  scripts in libgloss need to be updated to handle some new sections.

  In addition the linker scripts and startup code need to handle data
  that is stored in (high memory) flash RAM and which needs to be
  reinitialised when the processor is reset.

  The patch also tidies up the libgloss/msp430 directory, removing a few
  unneeded files.


2015-05-05  Nick Clifton  <nickc <at>>

	* msp430/msp430.ld: Delete.
	* msp430/msp430F5438A-l.ld: Delete.
	* msp430/msp430F5438A-s.ld: Delete.
	* msp430/crt_movedata.S: Delete.

	* msp430/ (SCRIPTS): Remove msp430.ld.
	(CRT_OBJS): Add crt_move_highdata.o.
	* msp430/memmodel.h (START_CRT_FUNC): New macro.
	(END_CRT_FUNC): New macro.
(Continue reading)

Junfeng Dong | 5 May 03:06 2015

crt0.o is missing with --target=i686-pc-linux-gnu

I build newlib with "--target=i686-pc-linux-gnu --prefix=", no ctr0.o
is compiled and installed. what is the problem?
My build machine is 64 bit ubuntu 14.04.

Best regards

Jeff Johnston | 5 May 00:47 2015

Newlib snapshot for 04/23/2015 created and put up on ftp site

See subject.

-- Jeff J.

Junfeng Dong | 3 May 11:11 2015

problems when doing cross compilation

I want to investigate newlib for our future IOT project. Now I got
problem to create a cross tool-chain base on newlib-,
binutils-2.17, gcc-4.8.4. My build machine is 64 bit Ubuntu 14.04, I
want build 32 bit toolchain for i586.

My build step is:
1. Macro export.
a. export TARGET=i386-linux-gnu
b. export PREFIX=/opt/newlib32
c. export PATH=$PATH:/opt/newlib32/bin
2. binutils build
a. SRC_DIR/configure --target=$TARGET --prefix=$PREFIX; make all -j8
CFLAGS="-Wno-error=unused-but-set-variable  -Wno-error=format-security
"; make install
3. Gcc build
a. SRC_DIR/configure --target=$TARGET --prefix=$PREFIX
--with-newlib --without-headers --with-gnu-as    --with-gnu-ld
--disable-shared --enable-languages=c    --disable-werror
--disable-decimal-float --disable-lib
b. make all-gcc CFLAGS_FOR_TARGET="-I
c. make install-gcc
4. newlib build
a. ../../newlib- --target=$TARGET
--prefix=$PREFIX CC=$TARGET-gcc LD=$TARGET-ld
b. Make all
Then I got the following error:
rm -f lib.a
(Continue reading)