Игорь Веневцев | 29 Jan 16:19 2016
Picon

[PATCH] Newlib build is broken if configured with nano-malloc and non-reentrant system calls

Non-reentrant system calls version implies both MISSING_SYSCALL_NAMES
and REENTRANT_SYSCALL_PROVIDED macros to be defined.
Being coupled with --enable-newlib-nano-malloc knob it breaks the build:

bash-4.3$ ../newlib-2.3.0.20160104/configure CC_FOR_TARGET=gcc
AR_FOR_TARGET=ar RANLIB_FOR_TARGET=ranlib CFLAGS_FOR_TARGET="-m32
-DMISSING_SYSCALL_NAMES -DREENTRANT_SYSCALLS_PROVIDED"
--target=i386-elf --enable-newlib-nano-malloc && make

<...omitted output...>

../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:
In function ‘_mallinfo_r’:
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:489:35:
error: macro "_sbrk_r" requires 2 arguments, but only 1 given
         sbrk_now = _sbrk_r(RCALL 0);
                                   ^
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:489:20:
error: ‘_sbrk_r’ undeclared (first use in this function)
         sbrk_now = _sbrk_r(RCALL 0);
                    ^
../../../../../../newlib-2.3.0.20160104/newlib/libc/stdlib/nano-mallocr.c:489:20:
note: each undeclared identifier is reported only once for each
function it appears in
Makefile:1512: recipe for target 'lib_a-nano-mallinfor.o' failed
make[8]: *** [lib_a-nano-mallinfor.o] Error 1

In case of non-reentrant system calls _sbrk_r became a macro with TWO
args (defined in reent.h):

(Continue reading)

Steve Ellcey | 28 Jan 18:18 2016
Steve Ellcey <sellcey <at> imgtec.com>

Subject: [Patch] Fix bug in MIPS memcpy.S routine

[Patch] Fix bug in MIPS memcpy.S routine

Joseph Myers found a bug in my last change to the MIPS memcpy routine and has
fixed it in glibc.  I would like to check in this patch to make the same fix
in newlib.  The bug was in having a load instruction in the delay slot of a
branch instruction and if the branch was taken we would end up loading a word
beyond the end of the input being copied.  The fix is to put a register move
in that delay slot instead since the move is harmless if the branch is taken
and needed if the branch is not taken.

Pointer to the glibc patch and discussion:

https://sourceware.org/ml/libc-alpha/2016-01/msg00566.html

OK to checkin the same fix to newlib?

Steve Ellcey
sellcey <at> imgtec.com

2016-01-28  Steve Ellcey  <sellcey <at> imgtec.com>

	* libc/machine/mips/memcpy.S (memcpy): Fix read past end of
	input.

diff --git a/newlib/libc/machine/mips/memcpy.S b/newlib/libc/machine/mips/memcpy.S
index 3130f6e..21bd3b4 100644
--- a/newlib/libc/machine/mips/memcpy.S
+++ b/newlib/libc/machine/mips/memcpy.S
 <at>  <at>  -581,11 +581,11  <at>  <at>  L(lastw):
 #ifdef USE_DOUBLE
 	andi    t8,a2,3		/* a2 is the remainder past 4 byte chunks.  */
 	beq	t8,a2,L(lastb)
(Continue reading)

Yaakov Selkowitz | 28 Jan 04:48 2016
Picon
Gravatar

[PATCH] grp.h: use __BSD_VISIBLE and __XSI_VISIBLE guards

This fixes the build of krb5 and other packages on Cygwin.

	* libc/include/grp.h: Use __BSD_VISIBLE and __XSI_VISIBLE guards.

Signed-off-by: Yaakov Selkowitz <yselkowi <at> redhat.com>
---
 newlib/libc/include/grp.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/newlib/libc/include/grp.h b/newlib/libc/include/grp.h
index c3a5a67..c75d525 100644
--- a/newlib/libc/include/grp.h
+++ b/newlib/libc/include/grp.h
 <at>  <at>  -71,21 +71,21  <at>  <at>  int		 getgrnam_r (const char *, struct group *,
 			char *, size_t, struct group **);
 int		 getgrgid_r (gid_t, struct group *,
 			char *, size_t, struct group **);
-#ifndef _POSIX_SOURCE
+#if __BSD_VISIBLE || __XSI_VISIBLE >= 500
 struct group	*getgrent (void);
 void		 setgrent (void);
 void		 endgrent (void);
 #ifndef __CYGWIN__
 void		 setgrfile (const char *);
 #endif /* !__CYGWIN__ */
-#ifndef _XOPEN_SOURCE
+#if __BSD_VISIBLE
 #ifndef __CYGWIN__
 char		*group_from_gid (gid_t, int);
 int		 setgroupent (int);
(Continue reading)

Joel Sherrill | 28 Jan 01:34 2016
Gravatar

cli/sti in i386/setjmp.S

Hi

Gedare and I are working on a paravirtualized port of RTEMS to
a hypervisor. The code will be running in user space which
changes the rules a bit over our normal bare metal environment.

Gedare debugged a test failure which turned out to be that
i386/setjmp.S uses sti/cli to protect this sequence of code
on bare metal (edi points to the jmpbuf):

        __CLI
	movl	28(edi),esp
	
	pushl	32(edi)	

	movl	0(edi),eax
	movl	4(edi),ebx
	movl	8(edi),ecx
	movl	12(edi),edx
	movl	16(edi),esi
	movl	20(edi),edi
        __STI
	ret

The cli/sti were turned into macros in 2000 and were apparently
there when the source code history started.

The only way I see the cli/sti needed is to protect against
the where where jmpbuf is on the stack and could be clobbered
by ISRs or signals being processed on the same stack while
(Continue reading)

Pieter du Preez | 25 Jan 21:19 2016
Picon

[PATCH] Automated the generation of the __NEWLIB__, __NEWLIB_MINOR__ and __NEWLIB_PATCHLEVEL__ macros.

Currently, the newlib version information needs to be setnewlib/acinclude.m4
in two places:
 - newlib/acinclude.m4
 - newlib/libc/include/sys/features.h

This patch moves the definition of the __NEWLIB__ and __NEWLIB_MINOR__
macros from newlib/libc/include/sys/features.h, to the generated
newlib/newlib.h file. Additionally, the __NEWLIB_PATCHLEVEL__ macro
was created, for completeness. This is in line with what gcc does
for its versioning macros.

Signed-off-by: Pieter du Preez <pdupreez <at> gmail.com>
---
 newlib/acinclude.m4                | 6 ++++--
 newlib/configure.in                | 3 +++
 newlib/libc/include/sys/features.h | 6 ------
 newlib/newlib.hin                  | 3 +++
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/newlib/acinclude.m4 b/newlib/acinclude.m4
index 9fefa32..a35264e 100644
--- a/newlib/acinclude.m4
+++ b/newlib/acinclude.m4
 <at>  <at>  -1,8 +1,10  <at>  <at> 
 dnl This provides configure definitions used by all the newlib
 dnl configure.in files.

-AC_DEFUN([DEF_NEWLIB_VERSION],
-m4_define([NEWLIB_VERSION],[2.3.0]))
+AC_DEFUN([DEF_NEWLIB_MAJOR_VERSION],m4_define([NEWLIB_MAJOR_VERSION],[2]))
(Continue reading)

Pei-Shiang Hung | 22 Jan 10:14 2016
Picon

Does nano-malloc support target without unaligned load/store instructions?

In nano-mallocr.c,
262     while (r)
263     {
264         int rem = r->size - alloc_size;
265         if (rem >= 0)
266         {
267             if (rem >= MALLOC_MINCHUNK)
268             {
269                 /* Find a chunk that much larger than required size, break
270                 * it into two chunks and return the second one */
271                 r->size = rem;
272                 r = (chunk *)((char *)r + rem);
273                 r->size = alloc_size;
274             }

line 272, it is dangerous to cast 'r' to 'char *', plus 'rem', then
cast back to 'chunk *'. What if the given 'rem' is not a word-aligned
number? It can cause unaligned access exception.  (This does happen in
my application.)

So, does nano-malloc be designed for specific target with unaligned
memory access instructions only(eg. ARM)?

Thanks all.

Zaibo Xu | 12 Jan 03:17 2016

[PATCH] Fix the bug of multiple cores print

1.  _VOID _DEFUN(__sinit, (s), struct _reent *s) in ./newlib/libc/stdio/findfp.c.
2. struct _reent in ./newlib/libc/include/sys/reent.h
Reasons: We have fount this bug in debuging the function of printf on
Sandybridge of Intel as multiple cores print to the cluster communication
port at the same time. After the mending above, this bug is fixed.

Signed-off-by: Zaibo Xu <xuzaibo <at> huawei.com>
---
 newlib/libc/include/sys/reent.h | 4 ++--
 newlib/libc/stdio/findfp.c      | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/newlib/libc/include/sys/reent.h b/newlib/libc/include/sys/reent.h
index 5481ca2..7b882fa 100644
--- a/newlib/libc/include/sys/reent.h
+++ b/newlib/libc/include/sys/reent.h
 <at>  <at>  -382,7 +382,7  <at>  <at>  struct _reent

   char *_emergency;

-  int __sdidinit;		/* 1 means stdio has been init'd */
+  volatile int __sdidinit;		/* 1 means stdio has been init'd */

   int _current_category;	/* unused */
   _CONST char *_current_locale;	/* unused */
 <at>  <at>  -580,7 +580,7  <at>  <at>  struct _reent
   int _current_category;	/* used by setlocale */
   _CONST char *_current_locale;

-  int __sdidinit;		/* 1 means stdio has been init'd */
(Continue reading)

Jeff Johnston | 4 Jan 19:11 2016
Picon

2.3.0 release fixes

Hello all,

Hope everyone had pleasant holidays.

I appear to have gummed up the 2.3.0 release in multiple ways starting with the fact that
I overwrote the index.html file with the 2.3.0 release.  As the release had a major issue with
regenerating the libc/aclocal.m4 file I have posted a snapshot release for 2.3.0 release dated
today 20160104.

-- Jeff J.

Freddie Chopin | 1 Jan 23:44 2016
Picon

Re: Regression with printf 8-bit format macros

On piątek, 1 stycznia 2016 12:08:30 CET Ambroz Bizjak wrote:
> Hello,
> 
> It appears to me that commit "Fix for pri and scn formats" [1] broke
> the 8-bit printf format macros (PRI*8), for scenarios when newlib is
> configured either with --enable-newlib-nano-formatted-io or without
> --enable-newlib-io-c99-format is not used. Because the new code
> defines these macros to the "hh" formats, which are not supported
> then.

Is it actually a problem that PRI* macros don't work without support for C99? 
After all, these are used for C99 types, so not really needed without C99...

Regards,
FCh

Ambroz Bizjak | 1 Jan 12:08 2016
Picon

Regression with printf 8-bit format macros

Hello,

It appears to me that commit "Fix for pri and scn formats" [1] broke
the 8-bit printf format macros (PRI*8), for scenarios when newlib is
configured either with --enable-newlib-nano-formatted-io or without
--enable-newlib-io-c99-format is not used. Because the new code
defines these macros to the "hh" formats, which are not supported
then.

I think the code should be changed so that the PRI*8 macros are
defined correctly even when printf does not support hh. The previous
definitions of these format macros didn't have length modifiers (they
were just i, d, x, X, etc.) and seemed to have worked, presumably due
to default-promotion of int8_t/uint8_t to int. The way I understand
the standard, it is not correct to e.g. use PRId8 but pass to printf
something which is not an int8, so it shouldn't be a problem that e.g.
printf("%"PRId8, 1000) actually prints 1000; what matters is that it
prints all the possible int8_t values correctly when passed an int8_t.

[1] https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=892cfcb7c2fbdc3b2b09c95a7a6c2065e5e0cfae

Best regards,
Ambroz

Jeff Johnston | 22 Dec 03:54 2015
Picon

Happy Holidays

To everyone, I will be away on Christmas vacation until the New Year
starting today.

If you celebrate Christmas, Merry Christmas, otherwise, Happy Holidays
and see you in the New Year.

-- Jeff J.


Gmane