qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stu


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]