>>> On 07.04.16 at 21:16, <andrew.coop...@citrix.com> wrote: > On 07/04/16 20:12, Jan Beulich wrote: >>>>> On 07.04.16 at 20:46, <andrew.coop...@citrix.com> wrote: >>> --- a/xen/Rules.mk >>> +++ b/xen/Rules.mk >>> @@ -50,9 +50,15 @@ ALL_OBJS-$(CONFIG_X86) += $(BASEDIR)/crypto/built_in.o >>> CFLAGS += -nostdinc -fno-builtin -fno-common >>> CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith >>> CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h >>> -CFLAGS += -Wa,--strip-local-absolute >>> CFLAGS += '-D__OBJECT_FILE__="$@"' >>> >>> +ifneq ($(clang),y) >>> +# Clang doesn't understand this command line argument, and doesn't appear >>> to >>> +# have an suitable alternative. The resulting compiled binary does >>> function, >>> +# but has an excessively large symbol table. >>> +CFLAGS += -Wa,--strip-local-absolute >>> +endif >> Well, that's the brute force undo-it-altogether-for-clang approach >> that I think Doug had also considered. You may have seen the >> discussion (on irc iirc) - I'd really like to see the option still getting >> passed to gas (for all the .S files) even when using clang. Would >> that really be hard to arrange for? > > That won't fix the fact that all the .c files which include > cpufeatureset.h also gets the absolute symbols, to allow the > alternatives() blocks to compile.
That's understood. > It will complicate the clang build quite a bit, and won't make much of a > dent on the symbol table bloat. While this I'm unclear about: Istr Doug mentioning that simply adding the option in suitable for to AFLAGS would do. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel