| Summary: | floor call (from math.h) is broken on qemuppc | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Stefan Stanacar <sstncr> |
| Component: | devtools / tool chain | Assignee: | Khem Raj <raj.khem> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | bruce.ashfield, elizabeth.flanagan, jessica.zhang, meta.mr.watcher, meta.watcher |
| Version: | 1.5 | ||
| Target Milestone: | 1.5 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
This works fine on real ppc(p2020) hardware. Could be qemu problem. another data point is that it works fine with uclibc/qemuppc now I wonder if it has to do with the machine 603e that we tune eglibc for when building it for qemuppc and the machine we use in qemu emulation which is G4/ppc7xxx, uclibc does not have any machine specific knowledge when it comes to these two ppc variants. *** Bug 4891 has been marked as a duplicate of this bug. *** khem: are we seeing the same thing with softfloat or turn on math emulation in the kernel ? I haven't checked if that's even possible for our mac99, but wanted to toss that out. We've seen plenty of softfloat -> math emu -> exception handling issues in the past with e500 cores, and this sounds similar. Where are we with this issue, it's a very visible failure on the Autobuilder due to the new sanity tests. I am not sure if this needs an updated tune or changes to eglibc, Khem can you please let us know so we can have someone else look into it if needed. Thanks (In reply to comment #5) > Where are we with this issue, it's a very visible failure on the Autobuilder > due to the new sanity tests. I am not sure if this needs an updated tune or > changes to eglibc, Khem can you please let us know so we can have someone > else > look into it if needed. Someone could play with tunings as I have suggested so to check if its not the mismatch between tunings and qemu emulation mode. Rule out tuning mismatch from suspects. Try using older 1.4.x qemu and see if it fails consistently there too rule out qemu from suspects. Other track is to is to look into eglibc's implementation itself I cant look into it this week but someone beats me to it all the better > > Thanks More data, I build master and dylan today and ran master against 1.4 qemu and 1.4 against master qemu (criss-cross). 1.4 Qemu with 1.4 Image = Good 1.4 Qemu with 1.5 Image = Good 1.5 Qemu with 1.4 Image = Bad 1.5 Qemu with 1.5 Image = Bad So the winner is something changed in the current version of Qemu, I am going to try a quick and dirty update to qemu_git. More info later. OK, bisect of qemu show this commit in qemu, this is as far as I can take this, I need someone with more PPC and Qemu know how to take this further 7d08d85645def18eac2a9d672c1868a35e0bcf79 is the first bad commit commit 7d08d85645def18eac2a9d672c1868a35e0bcf79 Author: Aurelien Jarno <aurelien@aurel32.net> Date: Sat Apr 20 08:56:22 2013 +0000 target-ppc: add support for extended mtfsf/mtfsfi forms Power ISA 2.05 adds support for extended mtfsf/mtfsfi form, with a new W field to select the upper part of the FPCSR register. For that the helper is changed to handle 64-bit input values and mask with up to 16 bits. The mtfsf/mtfsfi instructions do not have the W bit marked as invalid anymore. Instead this is checked in the helper, which therefore needs to access to the insns/insns_flags2. They are added in the DisasContext struct. Finally change all accesses to the opcode fields through extract helpers, prefixed with FP for consistency. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Alexander Graf <agraf@suse.de> This issue exists in the 3.10 kernel also, I tested with the latest linux-yocto-dev branch (AUTOREV'ed) At this point its most likely a QEMU regression, since the eglibc/floor() function works fine on real h/w I did a static compile of binary to make sure it uses the same floor() function which fails on qemu. I have initiated discussion on with qemu developers on this. The proposed patch works and thefore I have added it to qemu and sent out the patch on oe-core ml. Marked as Verified. |
poky commit: 74e403705e25afec656b5e40921771a9c29bdc40 1. Given 3 core-image-sato-sdk images for qemuarm, qemux86-64 and qemuppc and the following test.c file: ---cut here--- #include <stdio.h> #include <math.h> int main(int argc, char * argv[]) { double f = 1234.67; printf("floor(%f) = %f\n", f, floor(f)); return 0; } ---and here---- 2. copy the test.c file on the target and run on the target: gcc test.c -lm -o test ./test 3. The output will be: - on qemux86-64 and qemuarm: floor(1234.670000) = 1234.000000 - on qemuppc: floor(1234.670000) = 1235.000000 Now according to the floor man page: "floor, floorf, floorl - largest integral value not greater than argument These functions return the largest integral value that is not greater than x. For example, floor(0.5) is 0.0, and floor(-0.5) is -1.0" So, that's clearly broken on qemuppc. I haven't tested this with adt-installer nor meta-toolchain.