Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
reassign 673904 qemu thanks Steve M. Robbins s...@debian.org writes: Package: quemu Severity: important Tags: upstream [...] The default build of qemu64 advertises its CPU as something [...] quemu != qemu, the former does not exist. I reassigned your report to the appropriate package, as a valid report lingering in the void that is known as unknown packages is nonsensical and breaks the reporter's intention at least. ;) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
tags 673904 + wontfix thanks As I explained several times, this problem must be fixed on both sides - both gmp and qemu, and it is more correct to fix it in gmp side. The problem im gmp is that it uses abort() statements in cases where it detects impossible, to its thinking, CPU. Instead of these aborts(), it should just use whatever default optimization modes it already uses for these default cases. Ie, just changing abort() into break in the mentioned code in gmp is enough to fix it on gmp side. For qemu side, I don't want to make a Debian-specific change for this. If upstream decides to change default CPU type, Debian will inherit that change, and I'll happily backport it to the Debian package if that happens in some later upstream release. This is exactly why I started that discussion on qemu-devel list. So tagging as wontfix for now. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
[] As I explained several times, this problem must be fixed on both sides - both gmp and qemu, and it is more correct to fix it in gmp side. The problem im gmp is that it uses abort() statements in cases where it detects impossible, to its thinking, CPU. Instead of these aborts(), it should just use whatever default optimization modes it already uses for these default cases. Ie, just changing abort() into break in the mentioned code in gmp is enough to fix it on gmp side. For qemu side, I don't want to make a Debian-specific change for this. If upstream decides to change default CPU type, Debian will inherit that change, and I'll happily backport it to the Debian package if that happens in some later upstream release. This is exactly why I started that discussion on qemu-devel list. One additional note. I think I can manage a patch that will use kvm64 cpu type in case -enable-kvm is specified, and qemu64 if not. It will differ from upstream, which I dislike, but it should fix at least the current issue. ..Which is, indeed, can be trivially fixed externally by invoking qemu with the right options, explicitly specifying required CPU type and other machine details. That to say: this bugreport is only about default value of an option (-cpu), which has this value since the day one. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
On Tue, May 22, 2012 at 02:32:32PM +0400, Michael Tokarev wrote: tags 673904 + wontfix thanks As I explained several times, this problem must be fixed on both sides - both gmp and qemu, and it is more correct to fix it in gmp side. The problem im gmp is that it uses abort() statements in cases where it detects impossible, to its thinking, CPU. Forgive my re-hashing; I haven't seen these explanations. Pointers? To begin, why do you view GMP's behaviour as incorrect? Surely it is better to bail out on encountering an unknown (to GMP) CPU type rather than guess its capabilities? Instead of these aborts(), it should just use whatever default optimization modes it already uses for these default cases. Ie, just changing abort() into break in the mentioned code in gmp is enough to fix it on gmp side. I don't believe that is the case. If you look at the code all the break statements are preceded by setup code such as CPUVEC_SETUP_core2. The abort calls are preceeded by family/model combinations that indicate a 32-bit CPU which is nonsensical for a 64-bit gmp library. For qemu side, I don't want to make a Debian-specific change for this. Perhaps I'm missing something but I understood [1] to say that qemu could be configured to present itself as a known CPU type. That wouldn't require code changes, but a simple configuration change. [1] https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01390.html Thanks, -Steve signature.asc Description: Digital signature
Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
Package: quemu Severity: important Tags: upstream Hello, The default build of qemu64 advertises its CPU as something nonsensical such as a Pentuim II (not a 64 bit machine) [1]. This causes GMP's runtime detection of the CPU to fail, leading to gcc failure on some of the build daemon machines [2]. At the moment, GMP has reverted to using compile-time detection of the CPU type. This is not acceptable in the long term because it means: (a) the code may exhibit bugs if the user machine doesn't support opcodes that the build machine does; e.g. build on AMD 10h, run on AMD 11h [3] (b) the code may run at sub-optimal speed on user machines In thread [1], Paolo Bonzini claims [4]: You should use kvm32 and kvm64 instead. This may be a trivial fix for the matter. [1] https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01219.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671866 [3] http://gmplib.org/gmp5.0.html [4] https://lists.gnu.org/archive/html/qemu-devel/2012-05/msg01390.html -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
