| Message ID | 1464625676-17775-2-git-send-email-roger.pau@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 30.05.16 at 18:27, <roger.pau@citrix.com> wrote: > For all the build process, not only the assembly-only files. > > This prevents assembling certain code with the integrated assembler, while > other code would be assembled by the external assembler. Without you giving a reason why this needs to be that way, I don't think this is an acceptable change. I, for one, don't see why in a clang build we shouldn't use as much of clang as possible (and hence limit exceptions to a minimum). Jan
On Tue, May 31, 2016 at 02:16:49AM -0600, Jan Beulich wrote: > >>> On 30.05.16 at 18:27, <roger.pau@citrix.com> wrote: > > For all the build process, not only the assembly-only files. > > > > This prevents assembling certain code with the integrated assembler, while > > other code would be assembled by the external assembler. > > Without you giving a reason why this needs to be that way, I don't > think this is an acceptable change. I, for one, don't see why in a > clang build we shouldn't use as much of clang as possible (and hence > limit exceptions to a minimum). For once, the external and the integrated assembler might have a different set of features, so we would have to execute some of the checks twice against each of them and then choose the minimum set of features that are supported by both, IMHO we don't want to get down that road. Roger.
>>> On 31.05.16 at 12:31, <roger.pau@citrix.com> wrote: > On Tue, May 31, 2016 at 02:16:49AM -0600, Jan Beulich wrote: >> >>> On 30.05.16 at 18:27, <roger.pau@citrix.com> wrote: >> > For all the build process, not only the assembly-only files. >> > >> > This prevents assembling certain code with the integrated assembler, while >> > other code would be assembled by the external assembler. >> >> Without you giving a reason why this needs to be that way, I don't >> think this is an acceptable change. I, for one, don't see why in a >> clang build we shouldn't use as much of clang as possible (and hence >> limit exceptions to a minimum). > > For once, the external and the integrated assembler might have a different > set of features, so we would have to execute some of the checks twice > against each of them and then choose the minimum set of features that are > supported by both, IMHO we don't want to get down that road. Why not? These checks already say which flags they want to update. And I don't think many CONFIG_AS_* uses exist in .S files, so the amount of redundancy (to also update AFLAGS) would be small (or even zero). Jan
diff --git a/xen/Rules.mk b/xen/Rules.mk index 961d533..12efd6a 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -71,7 +71,7 @@ endif AFLAGS-y += -D__ASSEMBLY__ -include $(BASEDIR)/include/xen/config.h # Clang's built-in assembler can't handle .code16/.code32/.code64 yet -AFLAGS-$(clang) += -no-integrated-as +CFLAGS-$(clang) += -no-integrated-as ALL_OBJS := $(ALL_OBJS-y)
For all the build process, not only the assembly-only files. This prevents assembling certain code with the integrated assembler, while other code would be assembled by the external assembler. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> --- Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: George Dunlap <George.Dunlap@eu.citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Tim Deegan <tim@xen.org> Cc: Wei Liu <wei.liu2@citrix.com> --- xen/Rules.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)