[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#498008: marked as done (libc6: fedisableexcept/feenableexcept in ARMEL causes a SIGILL using ECL)

Your message dated Fri, 8 Dec 2017 19:16:41 +0100
with message-id <20171208181641.GA17348@aurel32.net>
and subject line Re: Bug#498008: libc6: fedisableexcept/feenableexcept in ARMEL causes a SIGILL using ECL
has caused the Debian Bug report #498008,
regarding libc6: fedisableexcept/feenableexcept in ARMEL causes a SIGILL using ECL
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
498008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498008
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.7-13
Severity: normal


The bug can be reproduced using ecl (lisp). The maintainer of ecl tracked the problem down on my device to

"ECL breaks right after booting because in __sigsetjmp() the system 
queries an internal register for the capabilities of the CPU and it finds that it has a coprocessor. 
However, this same query happened before and it returned false.

I tracked it down to the lines in src/c/unixint.c that activate the detection 
of floating point overflow. These are lines which make calls to fedisableexcept/feenableexcept 
"

You can reproduce the bug by
apt-get install ecl

a sigill is seen during installation.

As I got information that it is working on armv4 and armv5 I give you the detailed cpu information
Nokia-N800-23-14:~# cat /proc/cpuinfo 
Processor	: ARMv6-compatible processor rev 2 (v6l)
BogoMIPS	: 164.36
Features	: swp half thumb fastmult vfp edsp java 
CPU implementer	: 0x41
CPU architecture: 6TEJ
CPU variant	: 0x0
CPU part	: 0xb36
CPU revision	: 2
Cache type	: write-back
Cache clean	: cp15 c7 ops
Cache lockdown	: format C
Cache format	: Harvard
I size		: 32768
I assoc		: 4
I line length	: 32
I sets		: 256
D size		: 32768
D assoc		: 4
D line length	: 32
D sets		: 256

Hardware	: Nokia N800
Revision	: 24202524
Serial		: 0000000000000000



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armel (armv6l)

Kernel: Linux 2.6.21-omap1
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1                       1:4.3.1-9  GCC support library

libc6 recommends no packages.

Versions of packages libc6 suggests:
pn  glibc-doc                     <none>     (no description available)
ii  locales                       2.7-13     GNU C Library: National Language (

-- debconf information:
  glibc/upgrade: true
  glibc/restart-services:
  glibc/restart-failed:

--- End Message ---
--- Begin Message --- 
On 2008-09-06 09:27, D Schmicker wrote:
> Package: libc6
> Version: 2.7-13
> Severity: normal
> 
> 
> The bug can be reproduced using ecl (lisp). The maintainer of ecl tracked the problem down on my device to
> 
> "ECL breaks right after booting because in __sigsetjmp() the system 
> queries an internal register for the capabilities of the CPU and it finds that it has a coprocessor. 
> However, this same query happened before and it returned false.
> 
> I tracked it down to the lines in src/c/unixint.c that activate the detection 
> of floating point overflow. These are lines which make calls to fedisableexcept/feenableexcept 
> "
> 
> You can reproduce the bug by
> apt-get install ecl
> 
> a sigill is seen during installation.

I have looked the code of fedisableexcept and feenableexcept. They
indeed can call the rfs and wfs instructions, but they only do that if
the hardware actually has a VFP:

| int
| fedisableexcept (int excepts)
| {
|   fpu_control_t fpscr, new_fpscr;
| 
|   /* Fail if a VFP unit isn't present.  */
|   if (!ARM_HAVE_VFP)
|     return -1;
| 
|   _FPU_GETCW (fpscr);
|   excepts &= FE_ALL_EXCEPT;
|   new_fpscr = fpscr & ~(excepts << FE_EXCEPT_SHIFT);
| 
|   /* Write new exceptions if changed.  */
|   if (new_fpscr != fpscr)
|     _FPU_SETCW (new_fpscr);
| 
|   return (fpscr >> FE_EXCEPT_SHIFT) & FE_ALL_EXCEPT;
| }


> As I got information that it is working on armv4 and armv5 I give you the detailed cpu information
> Nokia-N800-23-14:~# cat /proc/cpuinfo 
> Processor	: ARMv6-compatible processor rev 2 (v6l)
> BogoMIPS	: 164.36
> Features	: swp half thumb fastmult vfp edsp java

This show the hardware has a VFP, or at least the kernel claims so. If
it's not the case, it's either a hardware issue or that the kernel does
not (lazily) enable the VFP while claiming it's available. That also
explains why this behaviour is not seen with other armv4t or armv5
machines.

As the kernel of the N800 is not supported in debian, I am closing this
bug on the libc side.

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

--- End Message ---
Reply to: