From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid() Date: Tue, 12 Nov 2013 16:21:10 +0100 Message-ID: <52824766.2000507@redhat.com> References: <5281580D.7060305@redhat.com> <52816422.8060002@redhat.com> <52821A62.2050001@redhat.com> <52822958.8060508@redhat.com> <20131112132337.GB2008@redhat.com> <528233DD.6020306@redhat.com> <20131112140935.GD2008@redhat.com> <528241E0.5060503@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Anthony Liguori , QEMU Developers , kvm-devel , Patch Tracking , Andreas Tobler , Anthony Liguori To: Peter Maydell Return-path: Received: from mail-ee0-f50.google.com ([74.125.83.50]:60500 "EHLO mail-ee0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753484Ab3KLPVR (ORCPT ); Tue, 12 Nov 2013 10:21:17 -0500 Received: by mail-ee0-f50.google.com with SMTP id b45so3219270eek.37 for ; Tue, 12 Nov 2013 07:21:16 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Il 12/11/2013 16:13, Peter Maydell ha scritto: >>> >> >>> >> -O1 then for clang. >> > >> > We can even test in configure for the exact optimizations we want, in >> > fact. But I think -O1 doesn't sacrifice debuggability that much: > I'm afraid I still don't see why you'd want to sacrifice it > at all, Is this FUD or do you have examples of bad debuggability of -O1 code? Personally, I've not even used -O0 for several years. -O2 debuggability is still awful but has improved a lot. If it's not enough, 99% of the time it means that tracing or printf are a better tool for the bug. > when the alternative is "provide a three line stub > function in a file we already have all the build machinery > to compile in the config where it's needed". I just don't > see why you'd worry about the fact that there's no longer > a compile error if you try to call this obviously kvm > specific function in a non-kvm-enabled code path, when > we already have large numbers of kvm-specific functions > that have stubs Most of these stubs do _not_ abort(), they return a sensible error code or should be no-ops in the non-KVM case. > (and when in general, eg QOM APIs, we seem > to be entirely happy to have things be runtime errors rather > than compile time). We're far from having consensus on that, indeed. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36452) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgFmV-0000cB-IW for qemu-devel@nongnu.org; Tue, 12 Nov 2013 10:21:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgFmH-0007bj-FL for qemu-devel@nongnu.org; Tue, 12 Nov 2013 10:21:31 -0500 Received: from mail-ea0-x232.google.com ([2a00:1450:4013:c01::232]:50809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgFmH-0007bB-8U for qemu-devel@nongnu.org; Tue, 12 Nov 2013 10:21:17 -0500 Received: by mail-ea0-f178.google.com with SMTP id a10so2935156eae.37 for ; Tue, 12 Nov 2013 07:21:16 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52824766.2000507@redhat.com> Date: Tue, 12 Nov 2013 16:21:10 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <5281580D.7060305@redhat.com> <52816422.8060002@redhat.com> <52821A62.2050001@redhat.com> <52822958.8060508@redhat.com> <20131112132337.GB2008@redhat.com> <528233DD.6020306@redhat.com> <20131112140935.GD2008@redhat.com> <528241E0.5060503@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Gleb Natapov , kvm-devel , Patch Tracking , QEMU Developers , Andreas Tobler , Anthony Liguori , Anthony Liguori Il 12/11/2013 16:13, Peter Maydell ha scritto: >>> >> >>> >> -O1 then for clang. >> > >> > We can even test in configure for the exact optimizations we want, in >> > fact. But I think -O1 doesn't sacrifice debuggability that much: > I'm afraid I still don't see why you'd want to sacrifice it > at all, Is this FUD or do you have examples of bad debuggability of -O1 code? Personally, I've not even used -O0 for several years. -O2 debuggability is still awful but has improved a lot. If it's not enough, 99% of the time it means that tracing or printf are a better tool for the bug. > when the alternative is "provide a three line stub > function in a file we already have all the build machinery > to compile in the config where it's needed". I just don't > see why you'd worry about the fact that there's no longer > a compile error if you try to call this obviously kvm > specific function in a non-kvm-enabled code path, when > we already have large numbers of kvm-specific functions > that have stubs Most of these stubs do _not_ abort(), they return a sensible error code or should be no-ops in the non-KVM case. > (and when in general, eg QOM APIs, we seem > to be entirely happy to have things be runtime errors rather > than compile time). We're far from having consensus on that, indeed. Paolo