Re: [Qemu-devel] [PATCH for-1.5 0/9] Disable expensive QOM cast debugging for official releases

[Paolo Bonzini <pbonzini@redhat.com>]

Il 10/05/2013 16:39, Anthony Liguori ha scritto:
> I just oppose the notion of disabling casts and *especially* only
> disabling casts for official builds.

This actually happens all the time.  Exactly this kind of type-safe cast
is disabled in releases of GCC, but enabled when building from svn trunk.

I have hardly seen any of these failures _during development_, much less
on a release.  I appreciate the advantage of type-safe casts, but in
QEMU they are a solution in search of a problem.  They are cheap to
implement (though not that cheap to execute ;)) so it's perfectly fine
to have them, but they are not _needed_; disabling them is anyway a good
build-time option to have.

Type-safe casts make sense in GTK+/GObject where: 1) type-safe casts
return NULL and log a "critical" error, they do not abort; 2) all
functions fail with another "critical" error if they are passed NULL.
We do neither, so we're just trading a crash now for a crash very soon
after (our call stacks tend to be relatively shallow, with some
exceptions such as the block layer).

Also, in GTK+/GObject the code paths are unpredictable because they
depend on user interaction, and a crash can lead to data loss.  By
contrast, in QEMU most of the code is hardly ever run, and the possible
paths are very few because driver writers tend to use always the same
path.  The day someone is bringing up a new guest OS and encounters such
a crash, we'll tell them to either build from git, or to use
--enable-qom-cast-debug.

I'm sure it will be a long time before that happens...

Paolo

> Regards,
> 
> Anthony Liguori
> 
>>> Either way, it would be nice to see the call sites of those
>>> most-impacting dynamic casts! So far I held back my APIC RFC since I'm
>>> not sure how to reproducibly profile things.
>>
>> It's interrupts (both sending and returning from them).
>>
>> Paolo
> 
> 
>