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

From: Roger Pau Monne <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [PATCH 2/2] build/clang: fix XSM dummy policy when using clang 4.0
Date: Mon, 6 Mar 2017 15:21:57 +0000	[thread overview]
Message-ID: <20170306152157.mqufnqz3tb72mc6w@dhcp-3-221.uk.xensource.com> (raw)
In-Reply-To: <58BD698E02000078001407A4@prv-mh.provo.novell.com>

On Mon, Mar 06, 2017 at 05:52:14AM -0700, Jan Beulich wrote:
> >>> On 06.03.17 at 13:31, <roger.pau@citrix.com> 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.
> 
> Especially from this perspective I think the patch is fine (but also
> Cc-ing Boris), yet I still think the compilation aspect needs to be got
> to the bottom of, to have a complete picture in case the problem
> shows up in a slightly different way elsewhere. Did you report this
> to clang folks? Did they have any explanation of what's going on?

I've just reported this upstream, for the record the ticket is at:

http://bugs.llvm.org/show_bug.cgi?id=32150

Roger.

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