Re: [Qemu-devel] [PATCH for-1.7] target-i386: Fix build by providing stub kvm_arch_get_supported_cpuid()

[Peter Maydell]

On 11 November 2013 23:11, Paolo Bonzini <address@hidden> wrote:
> Il 11/11/2013 23:38, Peter Maydell ha scritto:
>> If we have other places where we're relying on dead code elimination
>> to not provide a function definition, please point them out, because
>> they're bugs we need to fix, ideally before they cause compilation
>> failures.
>
> I'm not sure, there are probably a few others.  Linux also relies on the
> idiom (at least KVM does on x86).

Linux is notoriously tied to a particular compiler. I don't think QEMU
should be.

>> Huh? The point of stub functions is to provide versions of functions
>> which either need to return an "always fails" code, or which will never
>> be called, but in either case this is so we can avoid peppering the
>> code with #ifdefs. The latter category is why we have stubs which
>> do nothing but call abort().
>
> There are very few stubs that call abort():

You missed some more in stubs/, as it happens.

> Calling abort() would be marginally better than returning 0, but why
> defer checks to runtime when you can let the linker do them?

Because you can't guarantee that the compiler will
always throw the code out. As we can see here.

> Code which relies on dead-code-elimination is not broken, it's relying
> on the full power of the toolchain to ensure bugs are detected as soon
> as possible, i.e. at build time.

If you can point me at gcc and clang documentation that says
"we guarantee that we will dead-code eliminate these classes
of conditional at all levels of optimization" then I'm happy that
we can continue doing this and we have a clear level of what
we require that we're aiming at.

If you can't then we're relying on undocumented compiler
behaviour and we should stop.

> It's very obviously a random tweak aimed at a specific compiler's bug in
> dead-code elimination, I'm not denying that.

It's not a compiler bug. It's just not applying an optimization in
all the cases it possibly could. "Not as optimal as theoretically
possible" happens all the time for compilers.

I really don't see why anybody wants to rely on undocumented
compiler behaviour when the fix which means we have entirely
well defined behaviour is a single function in an already existing
stub file. What are the downsides here?

-- PMM