Re: [Xen-devel] [PATCH 1/2] x86/clang: fix build with indirect thunks

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Jan 25, 2018 at 02:39:36AM -0700, Jan Beulich wrote:
> >>> On 24.01.18 at 18:06, <roger.pau@xxxxxxxxxx> wrote:
> > On Wed, Jan 24, 2018 at 09:40:40AM -0700, Jan Beulich wrote:
> >> >>> On 24.01.18 at 16:48, <roger.pau@xxxxxxxxxx> wrote:
> >> > The build with clang is currently broken because clang requires asm
> >> > macros to be declared inside the same inline asm declaration where
> >> > they are used.
> >> 
> >> I don't understand this: What if I have two asm()-s needing it? Does
> >> this need to be done in each one? I'd expect this to result in duplicate
> >> definitions on gas then (which may or may not be benign).
> > 
> > It's quite fun, this approach works fine with clang regardless of the
> > number of asm()-s needing it. It doesn't complain about duplicate
> > macros or anything. OTOH gcc complains with "Error: Macro `foo' was
> > already defined".
> 
> And does clang need it in each asm()?

Yes. AFAICT .includes inside of asm()-s in clang are only valid inside
the same asm().

> Albeit - since the order
> functions are being output is undefined, it probably should go into
> each one. Hence the answer would only affect whether ...
> 
> > One option might be to guard indirect_thunk_asm.h with:
> > 
> > .ifndef INDIRECT_THUNK_ASM
> > .equ INDIRECT_THUNK_ASM, 1
> > 
> > ...
> > 
> > .endif
> 
> ... this would be needed conditionally for gas, or unconditionally.

The guard is needed unconditionally for gcc, or else having two
instances of the asm() in the same file is not going to work.

For gcc we could also avoid defining INCLUDE_INDIRECT_THUNK and keep
the same approach that's used currently, but I would rather have gcc
and clang using the same approach if possible.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel