Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
control: clone 916779 -1
control: reassign -1 gcc-8
control: retitle -1 gcc-8: --fno-math-errno causes GCC to consider that malloc 
does not set errno
control: submitted -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576

On 2018-12-22 13:37, Aurelien Jarno wrote:
> This is not what happens, errno is not set to ENOMEM in strerror_() but
> in strerror(). The problem is that the malloc implementation when run
> under QEMU sets errno to ENOMEM, despite successfully allocating the
> memory. errno is supposed to be saved around the malloc call:
> 
>   saved_errno = errno;
>   if (buf == NULL) 
> buf = malloc (1024);
>   __set_errno (saved_errno); 
> 
> That said, when compiled with -fno-math-errno, GCC optimizes out
> saving and restoring errno around the malloc call. I am not sure if this
> is a GCC bug or a bug in the GCC documentation.

This has been confirmed to be a GCC bug, here is the upstream bug
report:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576

As this bug is likely going to be workarounded in glibc, I am cloning
this bug and reassigning the clone to the gcc-8 package. I'll close the
glibc one when adding the workaround or a bumped build-dependency on
gcc-8.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Processed (with 1 error): Re: Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Debian Bug Tracking System
Processing control commands:

> clone 916779 -1
Bug #916779 [libc6-armhf-cross] libc6-armhf-cross: strerror(-3) sets errno to 
ENOMEM
Bug 916779 cloned as bug 917115
> reassign -1 gcc-8
Bug #917115 [libc6-armhf-cross] libc6-armhf-cross: strerror(-3) sets errno to 
ENOMEM
Bug reassigned from package 'libc6-armhf-cross' to 'gcc-8'.
No longer marked as found in versions cross-toolchain-base/30.
Ignoring request to alter fixed versions of bug #917115 to the same values 
previously set
> retitle -1 gcc-8: --fno-math-errno causes GCC to consider that malloc does 
> not set errno
Bug #917115 [gcc-8] libc6-armhf-cross: strerror(-3) sets errno to ENOMEM
Changed Bug title to 'gcc-8: --fno-math-errno causes GCC to consider that 
malloc does not set errno' from 'libc6-armhf-cross: strerror(-3) sets errno to 
ENOMEM'.
> submitted -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
Unknown command or malformed arguments to command.


-- 
916779: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916779
917115: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917115
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-22 19:42, Tim Rühsen wrote:
> On 22.12.18 16:56, Aurelien Jarno wrote:
> > The problem is that qemu-arm does not provide a heap to the program, so
> > glibc fails to alloc memory through brk. This causes malloc to switch to
> > mmap based memory allocation, and this also sets errno to ENOMEM.
> > 
> > printf also calls malloc, so the malloc implementation switches to
> > mmap based memory allocation at this moment. This is remembered through
> > the life of the program. When strerror then calls malloc(1024), the
> > allocation is done directly through mmap and errno is not set to ENOMEM.

Setting errno to ENOMEM happens during the call to MORECORE/sbrk in 
malloc/malloc.c in the following lines of the sysmalloc function:

|  if (size > 0)
|{
|  brk = (char *) (MORECORE (size));
|  LIBC_PROBE (memory_sbrk_more, 2, brk, size);
|}

Note however that clobbering errno is allowed even in case of success,
unless the contrary is specifically documented.

> > That's why you do not see the issue.
> > 
> > To reproduce the issue, you therefore need the following conditions:
> > - The kernel or QEMU does not provide a heap to the program
> > - malloc is not called (implicitly or explicitly) before the call to
> >   strerror
> > - strerror is called with an invalid error number.
> > 
> > If all of this 3 conditions are not met, the bug does not appear.
> 
> That is a good explanation and makes sense to me, thank you, Aurelien.
> 
> At least we can work around that issue now.
> 
> BTW, how do you debug cross-compiled executables ? There is no cross-gdb
> packaged in debian (or is there ?). Building that from scratch seems too
> time-intensive...

I have been rebuilding glibc, directly modifying the code being
debugged. ccache is really useful in that case.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Tim Rühsen
On 22.12.18 16:56, Aurelien Jarno wrote:
> On 2018-12-22 16:24, Tim Rühsen wrote:
>> On 22.12.18 13:37, Aurelien Jarno wrote:
>>> On 2018-12-21 12:58, Tim Rühsen wrote:
 On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> On 2018-12-21 11:51, Tim Rühsen wrote:
>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
 On 2018-12-18 21:34, Aurelien Jarno wrote:
> Hi,
>
> On 2018-12-18 15:15, Tim Ruehsen wrote:
>> Package: libc6-armhf-cross
>> Version: 2.28-2cross2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>
>> The expected errno value would be either EINVAL or not touching errno
>> at all.
>>
>> This behavior is relatively new and causes some CI cross builds to 
>> fail.
>> The failing test is a gnulib test (test-strerror.c).
>>
>
> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> think it's a qemu bug.

 Hmm, I am wrong, I can actually reproduce it with qemu-user-static
 version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>
>>> It seems to have been caused by this upstream patch:
>>>
>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>> | Author: Wilco Dijkstra 
>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>> | 
>>> | Add support for sqrt asm redirects
>>> | 
>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
>>> in GLIBC.
>>> | The goal is to enable GCC to do the inlining, and if this fails 
>>> call the
>>> | __ieee754_sqrt function.  This is done by internally declaring 
>>> sqrt with asm
>>> | redirects.  The compat symbols and sqrt wrappers need to disable 
>>> the redirect.
>>> | The redirect is also disabled if there are already redirects 
>>> defined when
>>> | using -ffinite-math-only.
>>> | 
>>> | All math functions (but not math tests, non-library code and 
>>> libnldbl) are
>>> | built with -fno-math-errno which means GCC will typically inline 
>>> sqrt as a
>>> | single instruction.  This means targets are no longer forced to 
>>> add a special
>>> | inline for sqrt.
>>> | 
>>> | * include/math.h (sqrt): Declare with asm redirect.
>>> | (sqrtf): Likewise.
>>> | (sqrtl): Likewise.
>>> | (sqrtf128): Likewise.
>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but 
>>> build testsuite,
>>> | nonlib and libnldbl with -fmath-errno.
>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>> | * math/w_sqrt_template.c: Likewise.
>>> | * math/w_sqrtf_compat.c: Likewise.
>>> | * math/w_sqrtl_compat.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
>>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
>>> math.h and
>>> | complex.h.
>>>
>>> And more precisely by building libc with -fno-math-errno.
>>
>> Thanks for looking into it.
>>
>> How is the proceeding ? Is there enough info to fix (or report upstream)
>> ? If not, what has to be done ?
>
> No it's not enough to fix it or report it upstream. We still have to
> understand the exact issue. For me it's not yet clear if the bug is in
> QEMU or in glibc. The fact that it works fine on real hardware would
> go towards a QEMU bug, but there is no proof yet.

 Looking at glibc's string/strerror.c, it calls __strerror_r() before
 saving errno.

 In __strerror_r(), gettext() is being called via a the #define _().

 gettext() saves/restores errno only if successful, else it doesn't.
 __strerror_r() doesn't check or save errno at all.

 So whenever gettext() sets errno, this value stays when strerror()
 returns. The gettext() code path is only travelled when errnum is < 0.

 You can of course argue, if gettext() or strerror() must be fixed. But
 that is clearly an upstream issue.

 And if there is an underlying issue with memory allocation is a
 different issue. But is doesn't affect the strerror() function in the
 gnulib test as it seems.
>>>
>>> This is not what happens, errno is not set to ENOMEM in strerror_() but
>>> in strerror(). The problem is that the malloc implementation when run
>>> under QEMU sets errno to ENOMEM, despite successfully 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-22 16:24, Tim Rühsen wrote:
> On 22.12.18 13:37, Aurelien Jarno wrote:
> > On 2018-12-21 12:58, Tim Rühsen wrote:
> >> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> >>> On 2018-12-21 11:51, Tim Rühsen wrote:
>  On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> > On 2018-12-18 22:11, Aurelien Jarno wrote:
> >> On 2018-12-18 21:34, Aurelien Jarno wrote:
> >>> Hi,
> >>>
> >>> On 2018-12-18 15:15, Tim Ruehsen wrote:
>  Package: libc6-armhf-cross
>  Version: 2.28-2cross2
>  Severity: normal
> 
>  Dear Maintainer,
> 
>  currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> 
>  The expected errno value would be either EINVAL or not touching errno
>  at all.
> 
>  This behavior is relatively new and causes some CI cross builds to 
>  fail.
>  The failing test is a gnulib test (test-strerror.c).
> 
> >>>
> >>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> >>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> >>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> >>> think it's a qemu bug.
> >>
> >> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> >> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> >
> > It seems to have been caused by this upstream patch:
> >
> > | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> > | Author: Wilco Dijkstra 
> > | Date:   Thu Mar 15 17:57:03 2018 +
> > | 
> > | Add support for sqrt asm redirects
> > | 
> > | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> > in GLIBC.
> > | The goal is to enable GCC to do the inlining, and if this fails 
> > call the
> > | __ieee754_sqrt function.  This is done by internally declaring 
> > sqrt with asm
> > | redirects.  The compat symbols and sqrt wrappers need to disable 
> > the redirect.
> > | The redirect is also disabled if there are already redirects 
> > defined when
> > | using -ffinite-math-only.
> > | 
> > | All math functions (but not math tests, non-library code and 
> > libnldbl) are
> > | built with -fno-math-errno which means GCC will typically inline 
> > sqrt as a
> > | single instruction.  This means targets are no longer forced to 
> > add a special
> > | inline for sqrt.
> > | 
> > | * include/math.h (sqrt): Declare with asm redirect.
> > | (sqrtf): Likewise.
> > | (sqrtl): Likewise.
> > | (sqrtf128): Likewise.
> > | * Makeconfig: Add -fno-math-errno for libc/libm, but 
> > build testsuite,
> > | nonlib and libnldbl with -fmath-errno.
> > | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> > | * math/w_sqrt_template.c: Likewise.
> > | * math/w_sqrtf_compat.c: Likewise.
> > | * math/w_sqrtl_compat.c: Likewise.
> > | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> > | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> > | * sysdeps/generic/math-type-macros-float128.h: Remove 
> > math.h and
> > | complex.h.
> >
> > And more precisely by building libc with -fno-math-errno.
> 
>  Thanks for looking into it.
> 
>  How is the proceeding ? Is there enough info to fix (or report upstream)
>  ? If not, what has to be done ?
> >>>
> >>> No it's not enough to fix it or report it upstream. We still have to
> >>> understand the exact issue. For me it's not yet clear if the bug is in
> >>> QEMU or in glibc. The fact that it works fine on real hardware would
> >>> go towards a QEMU bug, but there is no proof yet.
> >>
> >> Looking at glibc's string/strerror.c, it calls __strerror_r() before
> >> saving errno.
> >>
> >> In __strerror_r(), gettext() is being called via a the #define _().
> >>
> >> gettext() saves/restores errno only if successful, else it doesn't.
> >> __strerror_r() doesn't check or save errno at all.
> >>
> >> So whenever gettext() sets errno, this value stays when strerror()
> >> returns. The gettext() code path is only travelled when errnum is < 0.
> >>
> >> You can of course argue, if gettext() or strerror() must be fixed. But
> >> that is clearly an upstream issue.
> >>
> >> And if there is an underlying issue with memory allocation is a
> >> different issue. But is doesn't affect the strerror() function in the
> >> gnulib test as it seems.
> > 
> > This is not what happens, errno is not set to ENOMEM in strerror_() but
> > in strerror(). The problem is that the malloc implementation when run
> > under QEMU sets errno to ENOMEM, despite successfully allocating the
> > memory. errno is 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Tim Rühsen
On 22.12.18 13:37, Aurelien Jarno wrote:
> On 2018-12-21 12:58, Tim Rühsen wrote:
>> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
>>> On 2018-12-21 11:51, Tim Rühsen wrote:
 On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> On 2018-12-18 22:11, Aurelien Jarno wrote:
>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>> Hi,
>>>
>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
 Package: libc6-armhf-cross
 Version: 2.28-2cross2
 Severity: normal

 Dear Maintainer,

 currently strerror(-3) sets errno unexpectedly to ENOMEM (12).

 The expected errno value would be either EINVAL or not touching errno
 at all.

 This behavior is relatively new and causes some CI cross builds to 
 fail.
 The failing test is a gnulib test (test-strerror.c).

>>>
>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>> think it's a qemu bug.
>>
>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>
> It seems to have been caused by this upstream patch:
>
> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> | Author: Wilco Dijkstra 
> | Date:   Thu Mar 15 17:57:03 2018 +
> | 
> | Add support for sqrt asm redirects
> | 
> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> in GLIBC.
> | The goal is to enable GCC to do the inlining, and if this fails 
> call the
> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> with asm
> | redirects.  The compat symbols and sqrt wrappers need to disable 
> the redirect.
> | The redirect is also disabled if there are already redirects 
> defined when
> | using -ffinite-math-only.
> | 
> | All math functions (but not math tests, non-library code and 
> libnldbl) are
> | built with -fno-math-errno which means GCC will typically inline 
> sqrt as a
> | single instruction.  This means targets are no longer forced to add 
> a special
> | inline for sqrt.
> | 
> | * include/math.h (sqrt): Declare with asm redirect.
> | (sqrtf): Likewise.
> | (sqrtl): Likewise.
> | (sqrtf128): Likewise.
> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> testsuite,
> | nonlib and libnldbl with -fmath-errno.
> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> | * math/w_sqrt_template.c: Likewise.
> | * math/w_sqrtf_compat.c: Likewise.
> | * math/w_sqrtl_compat.c: Likewise.
> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> | * sysdeps/generic/math-type-macros-float128.h: Remove 
> math.h and
> | complex.h.
>
> And more precisely by building libc with -fno-math-errno.

 Thanks for looking into it.

 How is the proceeding ? Is there enough info to fix (or report upstream)
 ? If not, what has to be done ?
>>>
>>> No it's not enough to fix it or report it upstream. We still have to
>>> understand the exact issue. For me it's not yet clear if the bug is in
>>> QEMU or in glibc. The fact that it works fine on real hardware would
>>> go towards a QEMU bug, but there is no proof yet.
>>
>> Looking at glibc's string/strerror.c, it calls __strerror_r() before
>> saving errno.
>>
>> In __strerror_r(), gettext() is being called via a the #define _().
>>
>> gettext() saves/restores errno only if successful, else it doesn't.
>> __strerror_r() doesn't check or save errno at all.
>>
>> So whenever gettext() sets errno, this value stays when strerror()
>> returns. The gettext() code path is only travelled when errnum is < 0.
>>
>> You can of course argue, if gettext() or strerror() must be fixed. But
>> that is clearly an upstream issue.
>>
>> And if there is an underlying issue with memory allocation is a
>> different issue. But is doesn't affect the strerror() function in the
>> gnulib test as it seems.
> 
> This is not what happens, errno is not set to ENOMEM in strerror_() but
> in strerror(). The problem is that the malloc implementation when run
> under QEMU sets errno to ENOMEM, despite successfully allocating the
> memory. errno is supposed to be saved around the malloc call:
> 
>   saved_errno = errno;
>   if (buf == NULL) 
> buf = malloc (1024);
>   __set_errno (saved_errno); 
> 
> That said, when compiled with -fno-math-errno, GCC optimizes out
> saving and restoring errno around the malloc 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-21 12:19, Tim Rühsen wrote:
> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> > On 2018-12-21 11:51, Tim Rühsen wrote:
> >> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> >>> On 2018-12-18 22:11, Aurelien Jarno wrote:
>  On 2018-12-18 21:34, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2018-12-18 15:15, Tim Ruehsen wrote:
> >> Package: libc6-armhf-cross
> >> Version: 2.28-2cross2
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> >>
> >> The expected errno value would be either EINVAL or not touching errno
> >> at all.
> >>
> >> This behavior is relatively new and causes some CI cross builds to 
> >> fail.
> >> The failing test is a gnulib test (test-strerror.c).
> >>
> >
> > I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> > qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> > hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> > think it's a qemu bug.
> 
>  Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>  version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> >>>
> >>> It seems to have been caused by this upstream patch:
> >>>
> >>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> >>> | Author: Wilco Dijkstra 
> >>> | Date:   Thu Mar 15 17:57:03 2018 +
> >>> | 
> >>> | Add support for sqrt asm redirects
> >>> | 
> >>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> >>> in GLIBC.
> >>> | The goal is to enable GCC to do the inlining, and if this fails 
> >>> call the
> >>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> >>> with asm
> >>> | redirects.  The compat symbols and sqrt wrappers need to disable 
> >>> the redirect.
> >>> | The redirect is also disabled if there are already redirects 
> >>> defined when
> >>> | using -ffinite-math-only.
> >>> | 
> >>> | All math functions (but not math tests, non-library code and 
> >>> libnldbl) are
> >>> | built with -fno-math-errno which means GCC will typically inline 
> >>> sqrt as a
> >>> | single instruction.  This means targets are no longer forced to add 
> >>> a special
> >>> | inline for sqrt.
> >>> | 
> >>> | * include/math.h (sqrt): Declare with asm redirect.
> >>> | (sqrtf): Likewise.
> >>> | (sqrtl): Likewise.
> >>> | (sqrtf128): Likewise.
> >>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> >>> testsuite,
> >>> | nonlib and libnldbl with -fmath-errno.
> >>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> >>> | * math/w_sqrt_template.c: Likewise.
> >>> | * math/w_sqrtf_compat.c: Likewise.
> >>> | * math/w_sqrtl_compat.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> >>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
> >>> math.h and
> >>> | complex.h.
> >>>
> >>> And more precisely by building libc with -fno-math-errno.
> >>
> >> Thanks for looking into it.
> >>
> >> How is the proceeding ? Is there enough info to fix (or report upstream)
> >> ? If not, what has to be done ?
> > 
> > No it's not enough to fix it or report it upstream. We still have to
> > understand the exact issue. For me it's not yet clear if the bug is in
> > QEMU or in glibc. The fact that it works fine on real hardware would
> > go towards a QEMU bug, but there is no proof yet.
> 
> I think it's pretty clear: Under no circumstances must strerror() set
> errno to ENOMEM because this is against the specs [1].

I fully agree with that.

> That makes it pretty likely an upstream issue. Not sure about any Debian
> patches playing a role.

I disagree with that. This is a glibc upstream issue if the source code
is properly translated into binary code and if it is correctly executed
by the (virtual) CPU. I am still not convinced about both here.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-22 Thread Aurelien Jarno
On 2018-12-21 12:58, Tim Rühsen wrote:
> On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> > On 2018-12-21 11:51, Tim Rühsen wrote:
> >> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> >>> On 2018-12-18 22:11, Aurelien Jarno wrote:
>  On 2018-12-18 21:34, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2018-12-18 15:15, Tim Ruehsen wrote:
> >> Package: libc6-armhf-cross
> >> Version: 2.28-2cross2
> >> Severity: normal
> >>
> >> Dear Maintainer,
> >>
> >> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> >>
> >> The expected errno value would be either EINVAL or not touching errno
> >> at all.
> >>
> >> This behavior is relatively new and causes some CI cross builds to 
> >> fail.
> >> The failing test is a gnulib test (test-strerror.c).
> >>
> >
> > I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> > qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> > hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> > think it's a qemu bug.
> 
>  Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>  version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> >>>
> >>> It seems to have been caused by this upstream patch:
> >>>
> >>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> >>> | Author: Wilco Dijkstra 
> >>> | Date:   Thu Mar 15 17:57:03 2018 +
> >>> | 
> >>> | Add support for sqrt asm redirects
> >>> | 
> >>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) 
> >>> in GLIBC.
> >>> | The goal is to enable GCC to do the inlining, and if this fails 
> >>> call the
> >>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> >>> with asm
> >>> | redirects.  The compat symbols and sqrt wrappers need to disable 
> >>> the redirect.
> >>> | The redirect is also disabled if there are already redirects 
> >>> defined when
> >>> | using -ffinite-math-only.
> >>> | 
> >>> | All math functions (but not math tests, non-library code and 
> >>> libnldbl) are
> >>> | built with -fno-math-errno which means GCC will typically inline 
> >>> sqrt as a
> >>> | single instruction.  This means targets are no longer forced to add 
> >>> a special
> >>> | inline for sqrt.
> >>> | 
> >>> | * include/math.h (sqrt): Declare with asm redirect.
> >>> | (sqrtf): Likewise.
> >>> | (sqrtl): Likewise.
> >>> | (sqrtf128): Likewise.
> >>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> >>> testsuite,
> >>> | nonlib and libnldbl with -fmath-errno.
> >>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> >>> | * math/w_sqrt_template.c: Likewise.
> >>> | * math/w_sqrtf_compat.c: Likewise.
> >>> | * math/w_sqrtl_compat.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> >>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> >>> | * sysdeps/generic/math-type-macros-float128.h: Remove 
> >>> math.h and
> >>> | complex.h.
> >>>
> >>> And more precisely by building libc with -fno-math-errno.
> >>
> >> Thanks for looking into it.
> >>
> >> How is the proceeding ? Is there enough info to fix (or report upstream)
> >> ? If not, what has to be done ?
> > 
> > No it's not enough to fix it or report it upstream. We still have to
> > understand the exact issue. For me it's not yet clear if the bug is in
> > QEMU or in glibc. The fact that it works fine on real hardware would
> > go towards a QEMU bug, but there is no proof yet.
> 
> Looking at glibc's string/strerror.c, it calls __strerror_r() before
> saving errno.
> 
> In __strerror_r(), gettext() is being called via a the #define _().
> 
> gettext() saves/restores errno only if successful, else it doesn't.
> __strerror_r() doesn't check or save errno at all.
> 
> So whenever gettext() sets errno, this value stays when strerror()
> returns. The gettext() code path is only travelled when errnum is < 0.
> 
> You can of course argue, if gettext() or strerror() must be fixed. But
> that is clearly an upstream issue.
> 
> And if there is an underlying issue with memory allocation is a
> different issue. But is doesn't affect the strerror() function in the
> gnulib test as it seems.

This is not what happens, errno is not set to ENOMEM in strerror_() but
in strerror(). The problem is that the malloc implementation when run
under QEMU sets errno to ENOMEM, despite successfully allocating the
memory. errno is supposed to be saved around the malloc call:

  saved_errno = errno;
  if (buf == NULL) 
buf = malloc (1024);
  __set_errno (saved_errno); 

That said, when compiled with -fno-math-errno, GCC optimizes out
saving and restoring errno around the malloc call. I am not sure if this
is a GCC bug or a bug in the GCC documentation.

Note 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-21 Thread Tim Rühsen
On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> On 2018-12-21 11:51, Tim Rühsen wrote:
>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
 On 2018-12-18 21:34, Aurelien Jarno wrote:
> Hi,
>
> On 2018-12-18 15:15, Tim Ruehsen wrote:
>> Package: libc6-armhf-cross
>> Version: 2.28-2cross2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>
>> The expected errno value would be either EINVAL or not touching errno
>> at all.
>>
>> This behavior is relatively new and causes some CI cross builds to fail.
>> The failing test is a gnulib test (test-strerror.c).
>>
>
> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> think it's a qemu bug.

 Hmm, I am wrong, I can actually reproduce it with qemu-user-static
 version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>
>>> It seems to have been caused by this upstream patch:
>>>
>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>> | Author: Wilco Dijkstra 
>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>> | 
>>> | Add support for sqrt asm redirects
>>> | 
>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
>>> GLIBC.
>>> | The goal is to enable GCC to do the inlining, and if this fails call 
>>> the
>>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
>>> with asm
>>> | redirects.  The compat symbols and sqrt wrappers need to disable the 
>>> redirect.
>>> | The redirect is also disabled if there are already redirects defined 
>>> when
>>> | using -ffinite-math-only.
>>> | 
>>> | All math functions (but not math tests, non-library code and 
>>> libnldbl) are
>>> | built with -fno-math-errno which means GCC will typically inline sqrt 
>>> as a
>>> | single instruction.  This means targets are no longer forced to add a 
>>> special
>>> | inline for sqrt.
>>> | 
>>> | * include/math.h (sqrt): Declare with asm redirect.
>>> | (sqrtf): Likewise.
>>> | (sqrtl): Likewise.
>>> | (sqrtf128): Likewise.
>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
>>> testsuite,
>>> | nonlib and libnldbl with -fmath-errno.
>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>> | * math/w_sqrt_template.c: Likewise.
>>> | * math/w_sqrtf_compat.c: Likewise.
>>> | * math/w_sqrtl_compat.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
>>> | * sysdeps/generic/math-type-macros-float128.h: Remove math.h 
>>> and
>>> | complex.h.
>>>
>>> And more precisely by building libc with -fno-math-errno.
>>
>> Thanks for looking into it.
>>
>> How is the proceeding ? Is there enough info to fix (or report upstream)
>> ? If not, what has to be done ?
> 
> No it's not enough to fix it or report it upstream. We still have to
> understand the exact issue. For me it's not yet clear if the bug is in
> QEMU or in glibc. The fact that it works fine on real hardware would
> go towards a QEMU bug, but there is no proof yet.

Looking at glibc's string/strerror.c, it calls __strerror_r() before
saving errno.

In __strerror_r(), gettext() is being called via a the #define _().

gettext() saves/restores errno only if successful, else it doesn't.
__strerror_r() doesn't check or save errno at all.

So whenever gettext() sets errno, this value stays when strerror()
returns. The gettext() code path is only travelled when errnum is < 0.

You can of course argue, if gettext() or strerror() must be fixed. But
that is clearly an upstream issue.

And if there is an underlying issue with memory allocation is a
different issue. But is doesn't affect the strerror() function in the
gnulib test as it seems.

It's out of scope for me to cross-build the glibc. But if that is
possible for you, I'd suggest a fix (Debian patch ?) in strerror() until
it is fixed upstream.

Regards, Tim



signature.asc
Description: OpenPGP digital signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-21 Thread Tim Rühsen
On 12/21/18 12:09 PM, Aurelien Jarno wrote:
> On 2018-12-21 11:51, Tim Rühsen wrote:
>> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
>>> On 2018-12-18 22:11, Aurelien Jarno wrote:
 On 2018-12-18 21:34, Aurelien Jarno wrote:
> Hi,
>
> On 2018-12-18 15:15, Tim Ruehsen wrote:
>> Package: libc6-armhf-cross
>> Version: 2.28-2cross2
>> Severity: normal
>>
>> Dear Maintainer,
>>
>> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
>>
>> The expected errno value would be either EINVAL or not touching errno
>> at all.
>>
>> This behavior is relatively new and causes some CI cross builds to fail.
>> The failing test is a gnulib test (test-strerror.c).
>>
>
> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> think it's a qemu bug.

 Hmm, I am wrong, I can actually reproduce it with qemu-user-static
 version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
>>>
>>> It seems to have been caused by this upstream patch:
>>>
>>> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
>>> | Author: Wilco Dijkstra 
>>> | Date:   Thu Mar 15 17:57:03 2018 +
>>> | 
>>> | Add support for sqrt asm redirects
>>> | 
>>> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
>>> GLIBC.
>>> | The goal is to enable GCC to do the inlining, and if this fails call 
>>> the
>>> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
>>> with asm
>>> | redirects.  The compat symbols and sqrt wrappers need to disable the 
>>> redirect.
>>> | The redirect is also disabled if there are already redirects defined 
>>> when
>>> | using -ffinite-math-only.
>>> | 
>>> | All math functions (but not math tests, non-library code and 
>>> libnldbl) are
>>> | built with -fno-math-errno which means GCC will typically inline sqrt 
>>> as a
>>> | single instruction.  This means targets are no longer forced to add a 
>>> special
>>> | inline for sqrt.
>>> | 
>>> | * include/math.h (sqrt): Declare with asm redirect.
>>> | (sqrtf): Likewise.
>>> | (sqrtl): Likewise.
>>> | (sqrtf128): Likewise.
>>> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
>>> testsuite,
>>> | nonlib and libnldbl with -fmath-errno.
>>> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
>>> | * math/w_sqrt_template.c: Likewise.
>>> | * math/w_sqrtf_compat.c: Likewise.
>>> | * math/w_sqrtl_compat.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
>>> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
>>> | * sysdeps/generic/math-type-macros-float128.h: Remove math.h 
>>> and
>>> | complex.h.
>>>
>>> And more precisely by building libc with -fno-math-errno.
>>
>> Thanks for looking into it.
>>
>> How is the proceeding ? Is there enough info to fix (or report upstream)
>> ? If not, what has to be done ?
> 
> No it's not enough to fix it or report it upstream. We still have to
> understand the exact issue. For me it's not yet clear if the bug is in
> QEMU or in glibc. The fact that it works fine on real hardware would
> go towards a QEMU bug, but there is no proof yet.

I think it's pretty clear: Under no circumstances must strerror() set
errno to ENOMEM because this is against the specs [1].

That makes it pretty likely an upstream issue. Not sure about any Debian
patches playing a role.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html

Regards, Tim



signature.asc
Description: OpenPGP digital signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-21 Thread Aurelien Jarno
On 2018-12-21 11:51, Tim Rühsen wrote:
> On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> > On 2018-12-18 22:11, Aurelien Jarno wrote:
> >> On 2018-12-18 21:34, Aurelien Jarno wrote:
> >>> Hi,
> >>>
> >>> On 2018-12-18 15:15, Tim Ruehsen wrote:
>  Package: libc6-armhf-cross
>  Version: 2.28-2cross2
>  Severity: normal
> 
>  Dear Maintainer,
> 
>  currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> 
>  The expected errno value would be either EINVAL or not touching errno
>  at all.
> 
>  This behavior is relatively new and causes some CI cross builds to fail.
>  The failing test is a gnulib test (test-strerror.c).
> 
> >>>
> >>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> >>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> >>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> >>> think it's a qemu bug.
> >>
> >> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> >> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> > 
> > It seems to have been caused by this upstream patch:
> > 
> > | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> > | Author: Wilco Dijkstra 
> > | Date:   Thu Mar 15 17:57:03 2018 +
> > | 
> > | Add support for sqrt asm redirects
> > | 
> > | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
> > GLIBC.
> > | The goal is to enable GCC to do the inlining, and if this fails call 
> > the
> > | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> > with asm
> > | redirects.  The compat symbols and sqrt wrappers need to disable the 
> > redirect.
> > | The redirect is also disabled if there are already redirects defined 
> > when
> > | using -ffinite-math-only.
> > | 
> > | All math functions (but not math tests, non-library code and 
> > libnldbl) are
> > | built with -fno-math-errno which means GCC will typically inline sqrt 
> > as a
> > | single instruction.  This means targets are no longer forced to add a 
> > special
> > | inline for sqrt.
> > | 
> > | * include/math.h (sqrt): Declare with asm redirect.
> > | (sqrtf): Likewise.
> > | (sqrtl): Likewise.
> > | (sqrtf128): Likewise.
> > | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> > testsuite,
> > | nonlib and libnldbl with -fmath-errno.
> > | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> > | * math/w_sqrt_template.c: Likewise.
> > | * math/w_sqrtf_compat.c: Likewise.
> > | * math/w_sqrtl_compat.c: Likewise.
> > | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> > | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> > | * sysdeps/generic/math-type-macros-float128.h: Remove math.h 
> > and
> > | complex.h.
> > 
> > And more precisely by building libc with -fno-math-errno.
> 
> Thanks for looking into it.
> 
> How is the proceeding ? Is there enough info to fix (or report upstream)
> ? If not, what has to be done ?

No it's not enough to fix it or report it upstream. We still have to
understand the exact issue. For me it's not yet clear if the bug is in
QEMU or in glibc. The fact that it works fine on real hardware would
go towards a QEMU bug, but there is no proof yet.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-21 Thread Tim Rühsen
On 12/19/18 12:55 AM, Aurelien Jarno wrote:
> On 2018-12-18 22:11, Aurelien Jarno wrote:
>> On 2018-12-18 21:34, Aurelien Jarno wrote:
>>> Hi,
>>>
>>> On 2018-12-18 15:15, Tim Ruehsen wrote:
 Package: libc6-armhf-cross
 Version: 2.28-2cross2
 Severity: normal

 Dear Maintainer,

 currently strerror(-3) sets errno unexpectedly to ENOMEM (12).

 The expected errno value would be either EINVAL or not touching errno
 at all.

 This behavior is relatively new and causes some CI cross builds to fail.
 The failing test is a gnulib test (test-strerror.c).

>>>
>>> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
>>> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
>>> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
>>> think it's a qemu bug.
>>
>> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
>> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.
> 
> It seems to have been caused by this upstream patch:
> 
> | commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
> | Author: Wilco Dijkstra 
> | Date:   Thu Mar 15 17:57:03 2018 +
> | 
> | Add support for sqrt asm redirects
> | 
> | This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
> GLIBC.
> | The goal is to enable GCC to do the inlining, and if this fails call the
> | __ieee754_sqrt function.  This is done by internally declaring sqrt 
> with asm
> | redirects.  The compat symbols and sqrt wrappers need to disable the 
> redirect.
> | The redirect is also disabled if there are already redirects defined 
> when
> | using -ffinite-math-only.
> | 
> | All math functions (but not math tests, non-library code and libnldbl) 
> are
> | built with -fno-math-errno which means GCC will typically inline sqrt 
> as a
> | single instruction.  This means targets are no longer forced to add a 
> special
> | inline for sqrt.
> | 
> | * include/math.h (sqrt): Declare with asm redirect.
> | (sqrtf): Likewise.
> | (sqrtl): Likewise.
> | (sqrtf128): Likewise.
> | * Makeconfig: Add -fno-math-errno for libc/libm, but build 
> testsuite,
> | nonlib and libnldbl with -fmath-errno.
> | * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
> | * math/w_sqrt_template.c: Likewise.
> | * math/w_sqrtf_compat.c: Likewise.
> | * math/w_sqrtl_compat.c: Likewise.
> | * sysdeps/i386/fpu/w_sqrt.c: Likewise.
> | * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
> | * sysdeps/generic/math-type-macros-float128.h: Remove math.h and
> | complex.h.
> 
> And more precisely by building libc with -fno-math-errno.

Thanks for looking into it.

How is the proceeding ? Is there enough info to fix (or report upstream)
? If not, what has to be done ?

Regards, Tim




signature.asc
Description: OpenPGP digital signature


Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Aurelien Jarno
On 2018-12-18 22:11, Aurelien Jarno wrote:
> On 2018-12-18 21:34, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2018-12-18 15:15, Tim Ruehsen wrote:
> > > Package: libc6-armhf-cross
> > > Version: 2.28-2cross2
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> > > 
> > > The expected errno value would be either EINVAL or not touching errno
> > > at all.
> > > 
> > > This behavior is relatively new and causes some CI cross builds to fail.
> > > The failing test is a gnulib test (test-strerror.c).
> > > 
> > 
> > I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> > qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> > hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> > think it's a qemu bug.
> 
> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.

It seems to have been caused by this upstream patch:

| commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
| Author: Wilco Dijkstra 
| Date:   Thu Mar 15 17:57:03 2018 +
| 
| Add support for sqrt asm redirects
| 
| This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
GLIBC.
| The goal is to enable GCC to do the inlining, and if this fails call the
| __ieee754_sqrt function.  This is done by internally declaring sqrt with 
asm
| redirects.  The compat symbols and sqrt wrappers need to disable the 
redirect.
| The redirect is also disabled if there are already redirects defined when
| using -ffinite-math-only.
| 
| All math functions (but not math tests, non-library code and libnldbl) are
| built with -fno-math-errno which means GCC will typically inline sqrt as a
| single instruction.  This means targets are no longer forced to add a 
special
| inline for sqrt.
| 
| * include/math.h (sqrt): Declare with asm redirect.
| (sqrtf): Likewise.
| (sqrtl): Likewise.
| (sqrtf128): Likewise.
| * Makeconfig: Add -fno-math-errno for libc/libm, but build 
testsuite,
| nonlib and libnldbl with -fmath-errno.
| * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
| * math/w_sqrt_template.c: Likewise.
| * math/w_sqrtf_compat.c: Likewise.
| * math/w_sqrtl_compat.c: Likewise.
| * sysdeps/i386/fpu/w_sqrt.c: Likewise.
| * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
| * sysdeps/generic/math-type-macros-float128.h: Remove math.h and
| complex.h.

And more precisely by building libc with -fno-math-errno.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Aurelien Jarno
On 2018-12-18 21:34, Aurelien Jarno wrote:
> Hi,
> 
> On 2018-12-18 15:15, Tim Ruehsen wrote:
> > Package: libc6-armhf-cross
> > Version: 2.28-2cross2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> > 
> > The expected errno value would be either EINVAL or not touching errno
> > at all.
> > 
> > This behavior is relatively new and causes some CI cross builds to fail.
> > The failing test is a gnulib test (test-strerror.c).
> > 
> 
> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> think it's a qemu bug.

Hmm, I am wrong, I can actually reproduce it with qemu-user-static
version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Aurelien Jarno
Hi,

On 2018-12-18 15:15, Tim Ruehsen wrote:
> Package: libc6-armhf-cross
> Version: 2.28-2cross2
> Severity: normal
> 
> Dear Maintainer,
> 
> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> 
> The expected errno value would be either EINVAL or not touching errno
> at all.
> 
> This behavior is relatively new and causes some CI cross builds to fail.
> The failing test is a gnulib test (test-strerror.c).
> 

I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
think it's a qemu bug.

Do you have some other tests showing it's linked to the new upstream
glibc version?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

2018-12-18 Thread Tim Ruehsen
Package: libc6-armhf-cross
Version: 2.28-2cross2
Severity: normal

Dear Maintainer,

currently strerror(-3) sets errno unexpectedly to ENOMEM (12).

The expected errno value would be either EINVAL or not touching errno
at all.

This behavior is relatively new and causes some CI cross builds to fail.
The failing test is a gnulib test (test-strerror.c).

The behavior is not seen on an i368 cross build, while on all our other cross 
builds,
which are arm-linux-gnueabihf, mips-linux-gnu, aarch64-linux-gnu.

Here is a small reproducer:
include 
#include 
#include 

int main(void)
{
errno=0;
char *msg=strerror(-3);
printf("errno=%d, msg=%s\n",errno,msg);

return 0;
}

Test it with:
$ arm-linux-gnueabihf-gcc -Wextra x.c -o x
$ ./x
errno=12, msg=Unknown error -3

You need the binfmt/qemu stuff set up to execute the cross-compiled binary.

Regards, Tim

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled