Re: [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 03/06/2017 07:31 AM, Roger Pau Monne wrote:
> There seems to be some weird bug in clang 4.0 that prevents xsm_pmu_op from
> working as expected, and vpmu.o ends up with a reference to
> __xsm_action_mismatch_detected which makes the build fail:
>
> [...]
> ld    -melf_x86_64_fbsd  -T xen.lds -N prelink.o  \
>     xen/common/symbols-dummy.o -o xen/.xen-syms.0
> prelink.o: In function `xsm_default_action':
> xen/include/xsm/dummy.h:80: undefined reference to `__xsm_action_mismatch_detected'
> xen/xen/include/xsm/dummy.h:80: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__xsm_action_mismatch_detected'
> ld: xen/xen/.xen-syms.0: hidden symbol `__xsm_action_mismatch_detected' isn't defined
>
> Then doing a search in the objects files:
>
> # find xen/ -type f -name '*.o' -print0 | xargs -0 bash -c \
>   'for filename; do nm "$filename" | \
>   grep -q __xsm_action_mismatch_detected && echo "$filename"; done' bash
> xen/arch/x86/prelink.o
> xen/arch/x86/cpu/vpmu.o
> xen/arch/x86/cpu/built_in.o
> xen/arch/x86/built_in.o
>
> The current patch is the only way I've found to fix this so far, by simply
> moving the XSM_PRIV check into the default case in xsm_pmu_op. This also fixes
> the behavior of do_xenpmu_op, which will now return -EINVAL for unknown
> XENPMU_* operations, instead of -EPERM when called by a privileged domain.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

This also looks like a good patch for backporting.  The best alternative I
can think of is to disable the mismatch detection in non-DEBUG builds, but
I'd rather not do that unless this problem expands more than it has.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel