| Message ID | 1460054805-2393-1-git-send-email-andrew.cooper3@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> On 07.04.16 at 20:46, <andrew.cooper3@citrix.com> wrote: > The clang build already has many duplicate symbols for some reason I have yet > to identify, e.g. > > Duplicate symbol 'asid.c#get_cpu_info' (ffff82d0801e6840 != ffff82d0801c8190) > Duplicate symbol 'ats.c#__list_add' (ffff82d08015b900 != ffff82d0801546a0) > Duplicate symbol 'common.c#clear_bit' (ffff82d080213560 != ffff82d0801baf10) > Duplicate symbol 'common.c#constant_test_bit' (ffff82d080213550 != ffff82d0801ba750) > Duplicate symbol 'common.c#cpumask_check' (ffff82d080218c50 != ffff82d0801baf20) > Duplicate symbol 'common.c#cpumask_clear_cpu' (ffff82d080214990 != ffff82d0801bae40) > Duplicate symbol 'common.c#get_cpu_info' (ffff82d080212210 != ffff82d0801bad20) > > The resulting binary does function. Someone with more time can investigate > making symbol handling work better with Clang I'd guess that's because they don't inline functions as aggressively as gcc does. > --- 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? Jan
On 07/04/16 20:12, Jan Beulich wrote: >>>> On 07.04.16 at 20:46, <andrew.cooper3@citrix.com> wrote: >> The clang build already has many duplicate symbols for some reason I have yet >> to identify, e.g. >> >> Duplicate symbol 'asid.c#get_cpu_info' (ffff82d0801e6840 != ffff82d0801c8190) >> Duplicate symbol 'ats.c#__list_add' (ffff82d08015b900 != ffff82d0801546a0) >> Duplicate symbol 'common.c#clear_bit' (ffff82d080213560 != ffff82d0801baf10) >> Duplicate symbol 'common.c#constant_test_bit' (ffff82d080213550 != ffff82d0801ba750) >> Duplicate symbol 'common.c#cpumask_check' (ffff82d080218c50 != ffff82d0801baf20) >> Duplicate symbol 'common.c#cpumask_clear_cpu' (ffff82d080214990 != ffff82d0801bae40) >> Duplicate symbol 'common.c#get_cpu_info' (ffff82d080212210 != ffff82d0801bad20) >> >> The resulting binary does function. Someone with more time can investigate >> making symbol handling work better with Clang > I'd guess that's because they don't inline functions as aggressively > as gcc does. > >> --- 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. It will complicate the clang build quite a bit, and won't make much of a dent on the symbol table bloat. ~Andrew
>>> On 07.04.16 at 21:16, <andrew.cooper3@citrix.com> wrote: > On 07/04/16 20:12, Jan Beulich wrote: >>>>> On 07.04.16 at 20:46, <andrew.cooper3@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
On 07/04/16 20:21, Jan Beulich wrote: >>>> On 07.04.16 at 21:16, <andrew.cooper3@citrix.com> wrote: >> On 07/04/16 20:12, Jan Beulich wrote: >>>>>> On 07.04.16 at 20:46, <andrew.cooper3@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. In which case I clearly missed that bit on IRC. I am happy to defer to Doug's solution if it actually resolves the underlying issue. ~Andrew
On 4/7/16 2:21 PM, Jan Beulich wrote: >>>> On 07.04.16 at 21:16, <andrew.cooper3@citrix.com> wrote: >> On 07/04/16 20:12, Jan Beulich wrote: >>>>>> On 07.04.16 at 20:46, <andrew.cooper3@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 > I was trying to do exactly what you mentioned where we still passed it to gas and didn't pass it to llvm but unfortunately at some point the flags get combined together and passed to llvm and fails.
diff --git a/xen/Rules.mk b/xen/Rules.mk index d4dffde..7183d69 100644 --- 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 + CFLAGS-$(verbose) += -DVERBOSE CFLAGS-$(crash_debug) += -DCRASH_DEBUG CFLAGS-$(perfc) += -DPERF_COUNTERS
c/s 607044bf9 "build: avoid putting local absolute symbols in symbol tables" breaks the build with Clang, as the command line argument isn't understood. Clang does not appear to have any equivielent option, and already has outstanding issues with duplicate symbols. Excluding this option makes the problem no worse. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> The clang build already has many duplicate symbols for some reason I have yet to identify, e.g. Duplicate symbol 'asid.c#get_cpu_info' (ffff82d0801e6840 != ffff82d0801c8190) Duplicate symbol 'ats.c#__list_add' (ffff82d08015b900 != ffff82d0801546a0) Duplicate symbol 'common.c#clear_bit' (ffff82d080213560 != ffff82d0801baf10) Duplicate symbol 'common.c#constant_test_bit' (ffff82d080213550 != ffff82d0801ba750) Duplicate symbol 'common.c#cpumask_check' (ffff82d080218c50 != ffff82d0801baf20) Duplicate symbol 'common.c#cpumask_clear_cpu' (ffff82d080214990 != ffff82d0801bae40) Duplicate symbol 'common.c#get_cpu_info' (ffff82d080212210 != ffff82d0801bad20) The resulting binary does function. Someone with more time can investigate making symbol handling work better with Clang --- xen/Rules.mk | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)