[PATCH for-4.7 0/5] build: fixes for building Xen with clang

[PATCH for-4.7 0/5] build: fixes for building Xen with clang

[Roger Pau Monne]

This series contain small bug-fixes for building the Xen microkernel with
clang. I think they are suitable for 4.7, but that's just my opinion.

I've also noticed that Xen always sets "-no-integrated-as" when using clang,
because previous versions (<3.8.0) didn't support .code16/.code32/.code64
in inline asm. This is solved at least in version 3.8.0 (haven't tested
older versions). The problem now to switch to the integrated clang assembler
is the usage of the rept instructions in some files in conjunction with
labels:

entry.S:403:15: error: unexpected token in '.rept' directive
        .rept 48 -((.-compat_hypercall_table)/8)
              ^
entry.S:405:14: error: unmatched '.endr' directive
        .endr
             ^
entry.S:408:15: error: unexpected token in '.rept' directive
        .rept 64 -((.-compat_hypercall_table)/8)
              ^
entry.S:410:14: error: unmatched '.endr' directive
        .endr
             ^
entry.S:455:15: error: unexpected token in '.rept' directive
        .rept 48 -(.-compat_hypercall_args_table)
              ^
entry.S:457:14: error: unmatched '.endr' directive
        .endr
             ^
entry.S:460:15: error: unexpected token in '.rept' directive
        .rept 64 -(.-compat_hypercall_args_table)
              ^
entry.S:462:14: error: unmatched '.endr' directive
        .endr
             ^

The entry.S file this errors come from is xen/arch/x86/x86_64/compat/entry.S

If anyone has any clever ideas about how to replace those instructions with
compatible ones, I'm more than willing to listen. AFAICT, this is the last
issue that prevents Xen from switch to the integrated clang assembler on
newer clang versions.

Thanks, Roger.

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

[PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

[Roger Pau Monne]

Previously HOSTCC was always hardcoded to gcc

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 Config.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Config.mk b/Config.mk
index bfab893..deaa768 100644
--- a/Config.mk
+++ b/Config.mk
@@ -36,7 +36,6 @@ CONFIG_$(XEN_OS) := y
 SHELL     ?= /bin/sh
 
 # Tools to run on system hosting the build
-HOSTCC      = gcc
 HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
 HOSTCFLAGS += -fno-strict-aliasing
 
@@ -50,8 +49,10 @@ DESTDIR     ?= /
 clang ?= n
 ifeq ($(clang),n)
 gcc := y
+HOSTCC = gcc
 else
 gcc := n
+HOSTCC = clang
 endif
 
 
-- 
2.6.4 (Apple Git-63)


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

[PATCH for-4.7 2/5] build: set HOSTCXX based on clang value for Kconfig xconfig target

[Roger Pau Monne]

The xconfig Kconfig target requires a C++ compiler because it uses Qt.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 Config.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Config.mk b/Config.mk
index deaa768..5a31e2e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -50,9 +50,11 @@ clang ?= n
 ifeq ($(clang),n)
 gcc := y
 HOSTCC = gcc
+HOSTCXX = g++
 else
 gcc := n
 HOSTCC = clang
+HOSTCXX = clang++
 endif
 
 
-- 
2.6.4 (Apple Git-63)


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

[PATCH for-4.7 3/5] build: pass HOST{CC/CXX} value down to Kconfig

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
 xen/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/Makefile b/xen/Makefile
index c908544..b483823 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -242,14 +242,14 @@ kconfig := silentoldconfig oldconfig config menuconfig defconfig \
 	randconfig
 .PHONY: $(kconfig)
 $(kconfig):
-	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) $@
+	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) $@
 
 include/config/%.conf: include/config/auto.conf.cmd $(KCONFIG_CONFIG)
-	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) silentoldconfig
+	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) silentoldconfig
 
 # Allow people to just run `make` as before and not force them to configure
 $(KCONFIG_CONFIG):
-	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) defconfig
+	$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) SRCARCH=$(SRCARCH) HOSTCC=$(HOSTCC) HOSTCXX=$(HOSTCXX) defconfig
 
 # Break the dependency chain for the first run
 include/config/auto.conf.cmd: ;
-- 
2.6.4 (Apple Git-63)


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

[PATCH for-4.7 4/5] build: remove Kconfig forced gcc selection

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Doug Goldstein <cardoe@cardoe.com>
---
 xen/tools/kconfig/Makefile.kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/tools/kconfig/Makefile.kconfig b/xen/tools/kconfig/Makefile.kconfig
index 815f306..dbd8912 100644
--- a/xen/tools/kconfig/Makefile.kconfig
+++ b/xen/tools/kconfig/Makefile.kconfig
@@ -36,8 +36,8 @@ KBUILD_DEFCONFIG := $(ARCH)_defconfig
 CONFIG_SHELL := $(SHELL)
 
 # provide the host compiler
-HOSTCC := gcc
-HOSTCXX := g++
+HOSTCC ?= gcc
+HOSTCXX ?= g++
 
 # force target
 PHONY += FORCE
-- 
2.6.4 (Apple Git-63)


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

[PATCH for-4.7 5/5] travis: add an alias for gcc when using clang

[Roger Pau Monne]

In order to prevent it's usage. Since the tests are run on a Linux system
gcc is always present, so it's hard to detect if gcc is used in the clang
build.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Doug Goldstein <cardoe@cardoe.com>
---
 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis.yml b/.travis.yml
index 741a8ab..a6688cc 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -80,6 +80,7 @@ addons:
 before_script:
     - export CXX=${CC/cc/++}
     - export CXX=${CXX/clang/clang++}
+    - [ "x${clang}" = "xy" ] && alias gcc=false
 script:
     - ( [ "x${RANDCONFIG}" = "xy" ] && ( make -C xen randconfig )
       || exit 0 )
-- 
2.6.4 (Apple Git-63)


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

Re: [PATCH for-4.7 0/5] build: fixes for building Xen with clang

[Jan Beulich]

>>> Roger Pau Monne <roger.pau@citrix.com> 04/15/16 8:29 PM >>>
>I've also noticed that Xen always sets "-no-integrated-as" when using clang,
>because previous versions (<3.8.0) didn't support .code16/.code32/.code64
>in inline asm. This is solved at least in version 3.8.0 (haven't tested
>older versions). The problem now to switch to the integrated clang assembler
>is the usage of the rept instructions in some files in conjunction with
>labels:
>
>entry.S:403:15: error: unexpected token in '.rept' directive
>.rept 48 -((.-compat_hypercall_table)/8)
>^
>entry.S:405:14: error: unmatched '.endr' directive
>.endr
>[...]
>The entry.S file this errors come from is xen/arch/x86/x86_64/compat/entry.S
>
>If anyone has any clever ideas about how to replace those instructions with
>compatible ones, I'm more than willing to listen. AFAICT, this is the last
>issue that prevents Xen from switch to the integrated clang assembler on
>newer clang versions.

The question first of all is: What is it that is "unexpected" to their built-in
assembler? If they don't tolerate expressions involving the subtraction of
two addresses (or even expressions at all), then I'm afraid there's not much
we can do other than wait for them making their assembler more flexible.

Jan


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

Re: [PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

[Jan Beulich]

>>> Roger Pau Monne <roger.pau@citrix.com> 04/15/16 8:27 PM >>>
>Previously HOSTCC was always hardcoded to gcc

So what is the goal here? Be able to build on a gcc-free system? Or else, how
does it matter what compiler build elements get built with?

>--- a/Config.mk
>+++ b/Config.mk
>@@ -36,7 +36,6 @@ CONFIG_$(XEN_OS) := y
 >SHELL     ?= /bin/sh
 >
 ># Tools to run on system hosting the build
>-HOSTCC      = gcc
 >HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
 >HOSTCFLAGS += -fno-strict-aliasing
 >
>@@ -50,8 +49,10 @@ DESTDIR     ?= /
 >clang ?= n
 >ifeq ($(clang),n)
 >gcc := y
>+HOSTCC = gcc
 >else
 >gcc := n
>+HOSTCC = clang
 >endif
 
 In particular I wonder what this means for cross builds, where someone may
have installed e.g. only a cross variant of clang.

That said, I'm not really opposed to the change (as it seems to be at least an
incremental improvement), I only wonder whether some more thought (and
change) is needed here.

Jan


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

Re: [PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

[Roger Pau Monné]

On Sun, Apr 17, 2016 at 02:03:28PM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne <roger.pau@citrix.com> 04/15/16 8:27 PM >>>
> >Previously HOSTCC was always hardcoded to gcc
> 
> So what is the goal here? Be able to build on a gcc-free system? Or else, how
> does it matter what compiler build elements get built with?

Exactly. Newish FreeBSD versions (>=10 IIRC) only have clang in the base 
system.
 
> >--- a/Config.mk
> >+++ b/Config.mk
> >@@ -36,7 +36,6 @@ CONFIG_$(XEN_OS) := y
>  >SHELL     ?= /bin/sh
>  >
>  ># Tools to run on system hosting the build
> >-HOSTCC      = gcc
>  >HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
>  >HOSTCFLAGS += -fno-strict-aliasing
>  >
> >@@ -50,8 +49,10 @@ DESTDIR     ?= /
>  >clang ?= n
>  >ifeq ($(clang),n)
>  >gcc := y
> >+HOSTCC = gcc
>  >else
>  >gcc := n
> >+HOSTCC = clang
>  >endif
>  
>  In particular I wonder what this means for cross builds, where someone may
> have installed e.g. only a cross variant of clang.

Right, I think this should be ?= instead of =, so if a user has HOSTCC set 
in the build environment the build system doesn't overwrite it.
 
> That said, I'm not really opposed to the change (as it seems to be at least an
> incremental improvement), I only wonder whether some more thought (and
> change) is needed here.

IMHO, I think using ?= should at least be more correct, or if anyone has a 
better suggestion I'm happy to implement it.

Roger.

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

Re: [PATCH for-4.7 0/5] build: fixes for building Xen with clang

[Roger Pau Monné]

On Sun, Apr 17, 2016 at 04:02:02AM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne <roger.pau@citrix.com> 04/15/16 8:29 PM >>>
> >I've also noticed that Xen always sets "-no-integrated-as" when using clang,
> >because previous versions (<3.8.0) didn't support .code16/.code32/.code64
> >in inline asm. This is solved at least in version 3.8.0 (haven't tested
> >older versions). The problem now to switch to the integrated clang assembler
> >is the usage of the rept instructions in some files in conjunction with
> >labels:
> >
> >entry.S:403:15: error: unexpected token in '.rept' directive
> >.rept 48 -((.-compat_hypercall_table)/8)
> >^
> >entry.S:405:14: error: unmatched '.endr' directive
> >.endr
> >[...]
> >The entry.S file this errors come from is xen/arch/x86/x86_64/compat/entry.S
> >
> >If anyone has any clever ideas about how to replace those instructions with
> >compatible ones, I'm more than willing to listen. AFAICT, this is the last
> >issue that prevents Xen from switch to the integrated clang assembler on
> >newer clang versions.
> 
> The question first of all is: What is it that is "unexpected" to their built-in
> assembler? If they don't tolerate expressions involving the subtraction of
> two addresses (or even expressions at all), then I'm afraid there's not much
> we can do other than wait for them making their assembler more flexible.

The issue is that the clang assembler doesn't support using labels in asm 
directives, so it doesn't know how to resolve the 
(.-compat_hypercall_table). I've already filled a bug upstream:

https://llvm.org/bugs/show_bug.cgi?id=27369

I don't think we should expand that .rept directive manually, so I'm working 
with them in order to try to get their assembler to understand this.

Roger.

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

Re: [PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

[Jan Beulich]

>>> Roger Pau Monné <roger.pau@citrix.com> 04/20/16 4:51 PM >>>
>On Sun, Apr 17, 2016 at 02:03:28PM -0600, Jan Beulich wrote:
>> >>> Roger Pau Monne <roger.pau@citrix.com> 04/15/16 8:27 PM >>>
>> >@@ -50,8 +49,10 @@ DESTDIR     ?= /
>>  >clang ?= n
>>  >ifeq ($(clang),n)
>>  >gcc := y
>> >+HOSTCC = gcc
>>  >else
>>  >gcc := n
>> >+HOSTCC = clang
>>  >endif
>>  
>>  In particular I wonder what this means for cross builds, where someone may
>> have installed e.g. only a cross variant of clang.
>
>Right, I think this should be ?= instead of =, so if a user has HOSTCC set 
>in the build environment the build system doesn't overwrite it.
 >
>> That said, I'm not really opposed to the change (as it seems to be at least an
>> incremental improvement), I only wonder whether some more thought (and
>> change) is needed here.
>
>IMHO, I think using ?= should at least be more correct, or if anyone has a 
>better suggestion I'm happy to implement it.

Yes, that would at least eliminate some of my (admittedly vague) concerns.

Jan


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

Re: [PATCH for-4.7 3/5] build: pass HOST{CC/CXX} value down to Kconfig

[Ian Jackson]

Roger Pau Monne writes ("[PATCH for-4.7 3/5] build: pass HOST{CC/CXX} value down to Kconfig"):
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(supposing the previous two patches are adjusted as suggested)

Ian.

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