[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] hax_enabled() cannot be called in vl.c
From: |
Peter Maydell |
Subject: |
[Qemu-devel] hax_enabled() cannot be called in vl.c |
Date: |
Tue, 4 Dec 2018 14:45:15 +0000 |
In vl.c we do this:
if (hax_enabled()) {
hax_sync_vcpus();
}
But hax_enabled() varies depending on CONFIG_HAX: if that is
not defined then it is "#define hax_enabled() (0)", otherwise
it is a function. And CONFIG_HAX is a per-target configuration
define, only set for i386-softmmu and x86_64-softmmu.
Unfortunately, Makefile.objs puts vl.o in common-obj-y, meaning it
is built once and used for each target. So we can't use anything
here that has a target-specific definition.
My guess is that this is why this travis job has failed:
https://travis-ci.org/qemu/qemu/jobs/463302115
Undefined symbols for architecture x86_64:
"_hax_enabled", referenced from:
_qemu_main in vl.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [qemu-system-m68k] Error 1
(though it is a little odd that it has only just happened,
given that the code has been this way for some time AFAIK;
this may be a new config at the Travis end or a new target
we added to our Travis config.)
I'm not sure what the best fix is here -- perhaps following
how xen_enabled() works, where it is always defined as an
(inline) function which returns the xen_allowed bool.
kvm_enabled() does a similar thing to what hax_enabled() does,
but this works out OK because it takes care to avoid
providing the #define-to-0 implementation except in the
case where it is building a target-specific file for a
target where KVM is not enabled; for common files it
will provide the function prototype which will end up
linking to a stub implementation. So we could handle hax
like that too.
thanks
-- PMM
- [Qemu-devel] hax_enabled() cannot be called in vl.c,
Peter Maydell <=