<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>5248</bug_id>
          
          <creation_ts>2013-09-23 08:37:57 +0000</creation_ts>
          <short_desc>core-image-lsb: FPU doesn&apos;t work correctly on qemux86-64</short_desc>
          <delta_ts>2013-10-08 06:02:38 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>OE-Core</product>
          <component>devtools / tool chain</component>
          <version>1.5</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Multiple</op_sys>
          <bug_status>VERIFIED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>Medium+</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>1.5 M5</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Hongxu Jia">hongxu.jia</reporter>
          <assigned_to name="Saul Wold">sgw</assigned_to>
          <cc>bluelightning</cc>
    
    <cc>dvhart</cc>
    
    <cc>hongxu.jia</cc>
    
    <cc>liezhi.yang</cc>
    
    <cc>mark.hatle</cc>
    
    <cc>meta.mr.watcher</cc>
    
    <cc>meta.watcher</cc>
    
    <cc>Qi.Chen</cc>
    
    <cc>raj.khem</cc>
    
    <cc>richard.purdie</cc>
    
    <cc>rongqing.li</cc>
    
    <cc>ross.burton</cc>
    
    <cc>sgw</cc>
    
    <cc>tom.zanussi</cc>
    
    <cc>yi.zhao</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>---</cf_regression_type>
          
          <cf_docchange>Don&apos;t know</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>37044</commentid>
    <comment_count>0</comment_count>
    <who name="Hongxu Jia">hongxu.jia</who>
    <bug_when>2013-09-23 08:37:57 +0000</bug_when>
    <thetext>*Preparation
1, vim local.conf
...
DISTRO ?= &quot;poky-lsb&quot;
MACHINE ?= &quot;qemux86-64&quot;
...

*Problem
1, Build core-image-lsb
..
bitbake core-image-lsb
..

2, Start qemux86-64, there are 21 LSB tcl test failures on
qemux86-64[YOCTO #5167], you could reproduce it by tcl interpreter:
  1, On qemux86-64&apos;s terminal, start tcl interpreter
  root@qemux86-64:~# $ tclsh
  %

  2, Run &apos;binary scan&apos; to assign ieeeValues(-Subnormal)
  % binary scan \x00\x00\x00\x00\x00\x00\x08\x80 d ieeeValues(-Subnormal) 
  1

  3, Run &apos;puts&apos; to output ieeeValues(-Subnormal), the result is &apos;0.0&apos;
  % puts $ieeeValues(-Subnormal)
  -0.0

  Expected:
  -1.1125369292536007e-308

*Analysis
1, On the previous environment, add IMAGE_INSTALL_append = &quot; tcl&quot; to
local.conf and build core-image-sato, the result is expected.

2, Trace tcl&apos;s source code, you could also reproduce the issue by
compiling and executing the following C codes on core-image-lsb-sdk.

  1) Build core-image-lsb-sdk, and Run qemux86-64.
  2) On target&apos;s terminal, create a C source file:
     root@qemux86-64:~# cat &gt;&gt; test.c &lt;&lt; EOF
#include &lt;stdio.h&gt;

int main(int argc, char *argv[])
{
  double dd = 0;
  char *p = (char*)&amp;dd;
  p[0] = 0x00;
  p[1] = 0x00;
  p[2] = 0x00;
  p[3] = 0x00;
  p[4] = 0x00;
  p[5] = 0x00;
  p[6] = 0x08;
  p[7] = 0x00;

  if (dd == 0.0)
    printf(&quot;Incorrect equal 0.0\n&quot;);
  else
    printf(&quot;Expected not equal 0.0\n&quot;);

  return 0;
}
EOF

  2) Compile test.c
    root@qemux86-64:~# gcc test.c -o test

  3, Execute test
  $ root@qemux86-64:~# ./test
    Incorrect equal 0.0

  Expected:
    Expected not equal 0.0

3, It&apos;s about x86-64&apos;s FPU: the SSE MXCSR register.

  If you invoke &apos;feenableexcept(FE_INEXACT);&apos; or
  &apos;feclearexcept(FE_INEXACT);&apos; in the above C test,
  the issue will be fixed.

  In these two functions, the SSE MXCSR register has
  been handled.

http://en.wikipedia.org/wiki/Double-precision_floating-point_format
http://wiki.osdev.org/SSE</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37046</commentid>
    <comment_count>1</comment_count>
    <who name="Hongxu Jia">hongxu.jia</who>
    <bug_when>2013-09-23 08:39:58 +0000</bug_when>
    <thetext>*** Bug 5167 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37318</commentid>
    <comment_count>2</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2013-09-29 20:10:28 +0000</bug_when>
    <thetext>Well it took sometime and sleuthing via smaller and smaller build, but I 
tracked it down to the full version of procps and more specifically the running 
of sysctl at startup time.  Our base (non-lsb) images don&apos;t have a sysctl.conf 
by default, so it does not get run normally.  The LSB version has both a 
sysctl.conf and the sysctl.procps linked to sysctl, so syctl is run from 
bootmisc.sh.  I tested both busybox and sysctl.procps,   It seems running 
sysctl.procps causes the issue, but not the busybox version.  I can reproduce 
it without even passing any parameters to sysctl.procps

strace shows it doing very little:

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1070cc4000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1070cc3000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1070cc2000
arch_prctl(ARCH_SET_FS, 0x7f1070cc3700) = 0
mprotect(0x7f1070882000, 16384, PROT_READ) = 0
mprotect(0x7f1070ccf000, 4096, PROT_READ) = 0
munmap(0x7f1070cc5000, 36714)           = 0
brk(0)                                  = 0x603000
brk(0x624000)                           = 0x624000
open(&quot;/proc/version&quot;, O_RDONLY)         = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1070ccd000
read(3, &quot;Linux version 3.10.11-yocto-stan&quot;..., 1024) = 120
close(3)                                = 0
munmap(0x7f1070ccd000, 4096)            = 0
open(&quot;/sys/devices/system/cpu/online&quot;, O_RDONLY|O_CLOEXEC) = 3
read(3, &quot;0\n&quot;, 8192)                    = 2
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(4, 64), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
{B115200 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1070ccd000

Opens 2 /proc/version and /sys/devices/system/cpu/online, this issue seems to 
have something to do with the init_libproc() constructor</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37321</commentid>
    <comment_count>3</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2013-09-30 06:38:17 +0000</bug_when>
    <thetext>I narrowed this down a little further to the libgcc fast_math code (I think), 
not sure why it triggers with the procps but not other code yet.  It looks like 
it might be executing i386 code on the x86-64 machine, I need to check this 
furhter tommorow.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37322</commentid>
    <comment_count>4</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2013-09-30 06:43:05 +0000</bug_when>
    <thetext>I have added the following to local.conf and then mounted the 
core-image-minimal image and mv&apos;ed the /etc/sysctl.conf to /etc/sysctl.save 
(also mv /sbin/sysctl to /sbin/sysctl-), then try do debug /sbin/sysctl.psproc. 
 running the float program before and after will show correct and then 
incorrect.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37334</commentid>
    <comment_count>5</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2013-09-30 11:05:44 +0000</bug_when>
    <thetext>A data point from the test case on a NUC in 64-bit mode on core-image-sato.

root@nuc:~# uname -a
Linux nuc 3.10.11-yocto-standard #1 SMP PREEMPT Fri Sep 27 05:38:43 BST 2013 x86_64 GNU/Linux
root@nuc:~# ./test 
Expected not equal 0.0

After installing procps and rebooting:

root@nuc:~# ./test 
Expected not equal 0.0

I&apos;m doing a LSB build now, but does appear this is qemu-specific.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37353</commentid>
    <comment_count>6</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2013-09-30 13:43:43 +0000</bug_when>
    <thetext>And on core-image-lsb:

root@nuc:~# ./test 
Expected not equal 0.0</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37362</commentid>
    <comment_count>7</comment_count>
    <who name="Paul Eggleton">bluelightning</who>
    <bug_when>2013-09-30 16:14:34 +0000</bug_when>
    <thetext>Another data point - the issue is still present with QEMU 1.5.3.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37366</commentid>
    <comment_count>8</comment_count>
    <who name="Saul Wold">sgw</who>
    <bug_when>2013-09-30 17:19:40 +0000</bug_when>
    <thetext>Also verified that when running qemu with kvm it works correctly.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37368</commentid>
    <comment_count>9</comment_count>
    <who name="Khem Raj">raj.khem</who>
    <bug_when>2013-09-30 17:57:03 +0000</bug_when>
    <thetext>shot in dark but try 

http://sakrah.homelinux.org/files/fpip.patch

and see if it helps ?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37370</commentid>
    <comment_count>10</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2013-09-30 18:54:32 +0000</bug_when>
    <thetext>I found the problem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t2&amp;id=7eea15e10cb56b51aa27e246daac78d39d1b452a

Basically FXRSTOR was updating MXCSR but not the internal qemu status bits that need to change when that register changes.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37374</commentid>
    <comment_count>11</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2013-09-30 22:02:28 +0000</bug_when>
    <thetext>Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=0fe5d9d657446df695e8c810203da469e49ab553</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>37729</commentid>
    <comment_count>12</comment_count>
    <who name="Hongxu Jia">hongxu.jia</who>
    <bug_when>2013-10-08 06:02:38 +0000</bug_when>
    <thetext>Verified on master 5445f71fc812a5fcf9bd67a26a500284af16ad39


root@qemux86-64:~# tclsh
% binary scan \x00\x00\x00\x00\x00\x00\x08\x80 d ieeeValues(-Subnormal) 
1
% puts $ieeeValues(-Subnormal)
-1.1125369292536007e-308</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>