Jon TURNEY | 21 Jul 15:41 2015
Picon

[PATCH 0/6] More documentation fixes

Patches to fix a few errors and inconsistencies in the newlib documentation.

Jon TURNEY (6):
  Add missing NEWPAGE commands to makedoc markup in reent/
  Use makedoc generated texinfo documentation for reentrant syscalls
  Fix SYNPOSIS prototypes for iconv functions
  Fix a typo in iconv.tex
  Remove a stray sentence fragment in iconv.tex
  Remove workaround for texinfo bug with underscores in filenames from
    mothballed mathfp/

 newlib/libc/iconv/iconv.tex    |   3 +-
 newlib/libc/iconv/lib/iconv.c  |   8 +-
 newlib/libc/reent/execr.c      |   2 +
 newlib/libc/reent/signalr.c    |   1 +
 newlib/libc/sys.tex            | 189 +++++++++--------------------------------
 newlib/libm/mathfp/Makefile.am | 144 ++++++-------------------------
 6 files changed, 76 insertions(+), 271 deletions(-)

--

-- 
2.4.5

Jon TURNEY | 21 Jul 14:37 2015
Picon

[RFC][PATCH] Make manpages via DocBook XML


As I wrote a while ago, I've been looking for a better way to generate 
the Cygwin package containing manpages for newlib.

Attached is a patch implementing a replacement for the makedoc tool, 
which generates DocBook XML rather than .texinfo, which can then be 
processed into manpages and other formats.

I would appreciate any comments you have on the approach and the 
implementation.

There are at least the following issues with this patch:

* This only converts to DocBook the minimum necessary to generate manpages.

Converting the full content of libc.texinfo, libm.texinfo, sys.tex, 
reent.tex, iconv.tex, etc. is hard to do automatically, so would need to 
be done by hand.

Since maintaining the documentation in two formats seems unlikely to be 
a good idea, this would mean fully converting to DocBook, removing all 
the current texinfo source and .info generation and generating the .info 
from DocBook instead.

* There's a lot of boilerplate in all the Makefiles to generate 
documentation, and this adds more.  I don't know why this isn't in 
Makefile.shared

* This fails to fully achieve the objective of generating good manpages. 
   A few functions (e.g. sccanf, ssprintf) use nested tables in a way 
(Continue reading)

Andre Vieira | 14 Jul 15:30 2015

[PATCH ARM]Changed nano.specs to look for system headers in newlib-nano dir

Upon newlib-nano installation, the newlib.h configured for newlib-nano 
should be copied into a directory called newlib-nao, newly created in 
the installations include directory. The specs file for newlib-nano, 
nano.specs will now ensure that the preprocessor looks there first and 
thus uses the correct newlib.h for newlib-nano.

libgloss/ChangeLog
2015-06-30  Andre Vieira  <andre.simoesdiasvieira <at> arm.com\>

   \* arm/elf-nano.specs: Added option to search for system headers
   in newlib-nano directory.

Andre Vieira | 14 Jul 13:17 2015

print formats for FAST and LEAST types

Hello,

Kevin Bracey commented on Launchpad that he was having issues with a 
mismatch between <inttypes.h> and <stdint.h> when printing an 
int_fast32_t.  See 
https://answers.launchpad.net/gcc-arm-embedded/+question/269083

This is due to the fact that on targets where the size of ‘int’ and 
‘long’ are equal and 32 bits, the current header files will configure 
the type of int_fast32_t to be ‘int’ and PRIdFAST32 to be ‘ld’ and make 
printf thus expect a ‘long’. The macro’s used in <stdint.h> come from 
‘gcc/config/newlib-stdint.h’.

This leads to a print format warning when -Wformat and we are exploring 
two possible ways of fixing it and would like your views on which path 
would be best to take.

Approach 1)
Change the print formats for FAST (and LEAST) to reflect the types used 
in ‘gcc/config/newlib-stdint.h’. Less intrusive change. Though the fact 
that the approach for FASTNN and LEASTNN types is different from the one 
for INTNN types where ‘long’ is chosen over ‘int’ if they are equally 
sized does make us feel slightly uneasy.

Approach 2)
Change ‘gcc/config/newlib-stdint.h’ such that for targets where the size 
of ‘int’ and ‘long’ are the same,  ‘long’ is used for FASTNN and LEASTNN 
types where ‘int’ was used previously. This would mimic the behavior of 
INTNN types, though it is more intrusive.

(Continue reading)

jprofesorek | 12 Jul 17:18 2015
Picon

Newlib for armv6-m (ARM cortex-m0) and wrong assembly in trap.S

Hello,

I've been compiling newlib 2.2.0 for cortex-m0 (arch armv6-m), and I got the following error:

"trap.S:88: Error: lo register required -- `sub ip,sp,ip'"

As an ugly workaround I just commented out that line, and newlib compiled with no further issues.

The "sub ip,sp,ip" is clearly wrong for cortex-m0 - sub op can work on r0÷r7 only.

trap.S checks for !defined(__thumb2__) , but this arch is thumb.

My GCC was build with --with-cpu=cortex-m0 --with-mode=thumb, and, were it not, I'd probably get garbage
machine code from trap.S regardless.

I rested the resulting code on a real mcu, and the libs seem fine.

Would you please consider fixing this file somehow?

Regards,
Jan

Longer context of build messages:

arm-none-eabi-gcc
-B/tmp/portage/cross-arm-none-eabi/newlib-2.2.0/work/build/arm-none-eabi/newlib/ -isystem
/tmp/portage/cross-arm-none-eabi/newlib-2.2.0/work/build/arm-none-eabi/newlib/targ-include
-isystem /tmp/portage/cross-arm-none-eabi/newlib-2.2.0/work/newlib-2.2.0
/newlib/libc/include
-B/tmp/portage/cross-arm-none-eabi/newlib-2.2.0/work/build/arm-none-eabi/libgloss/arm
(Continue reading)

Wilco Dijkstra | 8 Jul 17:05 2015

[PATCH, AARCH64] Optimized memset

This is an optimized memset for AArch64. Memset is split into 4 main cases: small sets of up to 16
bytes, medium of 16..96 bytes which are fully unrolled. Large memsets of more than 96 bytes align
the destination and use an unrolled loop processing 64 bytes per iteration. Memsets of zero of more
than 256 use the dc zva instruction, and there are faster versions for the common ZVA sizes 64 or
128. STP of Q registers is used to reduce codesize without loss of performance.

ChangeLog:
2015-07-08  Wilco Dijkstra  <wdijkstr <at> arm.com>

	* newlib/libc/machine/aarch64/memset.S (memset): 
	Rewrite of optimized memset.

OK for commit?
---
 newlib/libc/machine/aarch64/memset.S | 386 +++++++++++++++++------------------
 1 file changed, 190 insertions(+), 196 deletions(-)

diff --git a/newlib/libc/machine/aarch64/memset.S b/newlib/libc/machine/aarch64/memset.S
index 20372df..379531a 100644
--- a/newlib/libc/machine/aarch64/memset.S
+++ b/newlib/libc/machine/aarch64/memset.S
 <at>  <at>  -4,13 +4,13  <at>  <at> 
    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
        * Redistributions of source code must retain the above copyright
-         notice, this list of conditions and the following disclaimer.
+	 notice, this list of conditions and the following disclaimer.
        * Redistributions in binary form must reproduce the above copyright
(Continue reading)

Wilco Dijkstra | 8 Jul 17:05 2015

[PATCH, AARCH64] Optimized memmove

This is an optimized memmove for AArch64. All copies of up to 96 bytes and all backward copies are
done by the new memcpy. The only remaining case is large forward copies which are done in the same
way as the memcpy loop, but copying from the end rather than the start. Speedup is similar as
memcpy.

ChangeLog:
2015-07-08  Wilco Dijkstra  <wdijkstr <at> arm.com>

	* newlib/libc/machine/aarch64/memove.S (memmove):
	Rewrite of optimized memmove.

OK for commit?
---
 newlib/libc/machine/aarch64/memmove.S | 400 ++++++++++------------------------
 1 file changed, 113 insertions(+), 287 deletions(-)

diff --git a/newlib/libc/machine/aarch64/memmove.S b/newlib/libc/machine/aarch64/memmove.S
index 8cb91f0..d8c9ba3 100644
--- a/newlib/libc/machine/aarch64/memmove.S
+++ b/newlib/libc/machine/aarch64/memmove.S
 <at>  <at>  -4,13 +4,13  <at>  <at> 
    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
        * Redistributions of source code must retain the above copyright
-         notice, this list of conditions and the following disclaimer.
+	 notice, this list of conditions and the following disclaimer.
        * Redistributions in binary form must reproduce the above copyright
-         notice, this list of conditions and the following disclaimer in the
(Continue reading)

Wilco Dijkstra | 8 Jul 17:05 2015

[PATCH, AARCH64] Optimized memcpy

This is an optimized memcpy for AArch64. Copies are split into 3 main cases: small copies of up to
16 bytes, medium copies of 17..96 bytes which are fully unrolled. Large copies of more than 96 bytes
align the destination and use an unrolled loop processing 64 bytes per iteration. In order to share
code with memmove, small and medium copies read all data before writing, allowing any kind of
overlap. On a random copy test memcpy is 40.8% faster on A57 and 28.4% on A53.

ChangeLog:
2015-07-08  Wilco Dijkstra  <wdijkstr <at> arm.com>

	* newlib/libc/machine/aarch64/memcpy.S (memcpy):
	Rewrite of optimized memcpy.

OK for commit?
---
 newlib/libc/machine/aarch64/memcpy.S | 305 +++++++++++++++++++----------------
 1 file changed, 166 insertions(+), 139 deletions(-)

diff --git a/newlib/libc/machine/aarch64/memcpy.S b/newlib/libc/machine/aarch64/memcpy.S
index ef5c3a9..e2705fd 100644
--- a/newlib/libc/machine/aarch64/memcpy.S
+++ b/newlib/libc/machine/aarch64/memcpy.S
 <at>  <at>  -4,13 +4,13  <at>  <at> 
    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions are met:
        * Redistributions of source code must retain the above copyright
-         notice, this list of conditions and the following disclaimer.
+	 notice, this list of conditions and the following disclaimer.
        * Redistributions in binary form must reproduce the above copyright
(Continue reading)

Yaakov Selkowitz | 6 Jul 20:10 2015
Picon

[PATCH] Rework handling of basename variants

As a commonly-included header, the #define basename in <string.h> can
affect code which uses "basename" for its own purposes (e.g. struct
members or C++ namespaced functions).  When such cases occur and some
code includes <string.h> and some not, then errors result.  OTOH,
<libgen.h> is rarely used, and that's where the renaming occurs in
glibc, so code using <libgen.h> should already be safe.
---
 newlib/libc/include/libgen.h | 5 +++--
 newlib/libc/include/string.h | 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/newlib/libc/include/libgen.h b/newlib/libc/include/libgen.h
index de70b5b..3c717c5 100644
--- a/newlib/libc/include/libgen.h
+++ b/newlib/libc/include/libgen.h
 <at>  <at>  -6,6 +6,7  <at>  <at> 
 #define _LIBGEN_H_
 
 #include "_ansi.h"
+#include <sys/cdefs.h>
 #include <sys/reent.h>

 #ifdef __cplusplus
 <at>  <at>  -24,8 +25,8  <at>  <at>  extern "C" {
    this also implies that the POSIX version is used in this case.  That's made
    sure here. */
 #undef basename
-#define basename basename
-char      *_EXFUN(basename,     (char *));
+#define basename __xpg_basename
(Continue reading)

Kline, Matthew | 2 Jul 19:58 2015

sprintf misbehaving with floats

Hello all,

I'm using newlib for some firmware I'm developing on an ARM Cortex-M4
(a STM32F427ZIT6, FWIW), and I'm running into a bit of trouble.

printf and family (sprintf, etc.) seem to misbehave when given floating point
values. The following produces the intended result:

static char foo[1024];
sprintf(foo, "%d is an int", 42);

But the following

sprintf(foo, "%f is a float", 8675.309f);

produces garbage similar to

00000000: 0000 0320 2e49 3802 08d1 0320 6973 2061  ... .I8.... is a
00000010: 2066 6c6f 6174 0000 0000 0000 0000 0000   float..........

Oddly enough, it seems to return the correct value and write a string of the
right length, but the characters where the float should go are badly messed up.

I'm aware that newlib can be built without support for printing and scanning
floats using --disable-newlib-io-float, but my distro package that provides
newlib isn't being built with that flag. The package build script can be found
at https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/arm-none-eabi-newlib
and is being built with the following flags:

--disable-newlib-supplied-syscalls \
(Continue reading)

Colin Percival | 1 Jul 22:03 2015

[bug] string.h inadequately respects __POSIX_VISIBLE

[Please CC on replies, since I'm not subscribed to the list.]

Hi all,

I distribute some code (spiped) which sets _POSIX_C_SOURCE=200809L, in an
attempt at strict POSIX conformance.  Alas, this triggers a conformance
bug in newlib.

In newlib/libc/include/sys/cdefs.h this value is correctly translated to
define __POSIX_VISIBLE:

 654 #if _POSIX_C_SOURCE >= 200809
 655 #define __POSIX_VISIBLE         200809
 656 #define __ISO_C_VISIBLE         1999

but __POSIX_VISIBLE is not respected in newlib/libc/include/string.h when
strdup is declared:
  79 #if __XSI_VISIBLE >= 500
  80 char    *_EXFUN(strdup,(const char *));
  81 #endif

The test in this case should be
     #if __POSIX_VISIBLE >= 200112 || __XSI_VISIBLE >= 500

It looks like strdup is the only function you're missing from string.h,
but there are several others which you're declaring unconditionally or
simply based on __POSIX_VISIBLE being defined rather than checking the
exact value.  I haven't checked the other header files in your libc.

--

-- 
(Continue reading)


Gmane