Re: [Xen-devel] [PATCH for-4.7] xen/build: Fix build with Clang

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.04.16 at 21:16, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 07/04/16 20:12, Jan Beulich wrote:
>>>>> On 07.04.16 at 20:46, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel