[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] hw/i386: fix short-circuit logic with non-optimizing builds
|
From: |
Michael S. Tsirkin |
|
Subject: |
Re: [PATCH] hw/i386: fix short-circuit logic with non-optimizing builds |
|
Date: |
Sun, 19 Nov 2023 15:02:33 -0500 |
On Sun, Nov 19, 2023 at 11:03:54AM -0600, Dan Hoffman wrote:
> On Sun, Nov 19, 2023 at 1:23 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Sat, Nov 18, 2023 at 10:25:31AM -0800, Daniel Hoffman wrote:
> > > `kvm_enabled()` is compiled down to `0` and short-circuit logic is
> > > used to remmove references to undefined symbols at the compile stage.
> > > Some build configurations with some compilers don't attempt to
> > > simplify this logic down in some cases (the pattern appears to be
> > > that the literal false must be the first term) and this was causing
> > > some builds to emit references to undefined symbols.
> > >
> > > Signed-off-by: Daniel Hoffman <dhoff749@gmail.com>
> >
> > Could we add a bit more detail here? Will help make sure
> > this does not break again in the future.
>
> The configuration script was ran as such: ../configure
> --without-default-features --target-list=x86_64-softmmu,i386-softmmu
> --enable-debug --enable-tcg-interpreter --enable-debug-tcg
> --enable-debug-mutex
>
> I'm pretty sure the only relevant flags here are
> --without-default-features, --target-list including x86_64-softmmu and
> --enable-debug
>
> The only error I see is this: [...]/hw/i386/x86.c:422:(.text+0x1004):
> undefined reference to `kvm_hv_vpindex_settable' (the other
> kvm_enabled() was moved for the sake of consistency). My compiler is
> clang (16.0.6).
>
> I haven't looked into the heuristics or logic for how the compile-time
> short-circuit logic works, but I assumed only the first parameter is
> "guaranteed" to be checked for a literal false (guaranteed is in
> quotes because that's just how clang works, not because it's a feature
> of the language IIRC).
>
> This pattern relies on somes subtle behavior with the compiler, so my
> suggestion going forward would be to not rely on code optimizations
> removing undefined references based on short-circuit logic (instead
> have some configuration macro defined that disables all relevant
> code). I'm a new contributor, so I submitted the minimum to make it
> work on my machine.
>
> If you have any other questions, please let me know.
>
> Thanks!
which compiler is this?
--
MST