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
