[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table
>>> On 02.11.15 at 16:20, <ian.campbell@xxxxxxxxxx> wrote: > On Mon, 2015-10-26 at 05:50 -0600, Jan Beulich wrote: >> To make it possible to tell apart the static symbols in files built a >> second for compat guest support, arrange for their source file names to > > ^ time ? Oh, yes, of course. >> --- a/xen/Rules.mk >> +++ b/xen/Rules.mk >> @@ -86,8 +86,7 @@ AFLAGS-$(clang) += -no-integrate >> ALL_OBJS := $(ALL_OBJS-y) >> >> # Get gcc to generate the dependencies for us. >> -CFLAGS-y += -MMD -MF .$(@F).d >> -DEPS = .*.d >> +CFLAGS-y += -MMD -MF $(@D)/.$(@F).d >> >> CFLAGS += $(CFLAGS-y) >> >> @@ -103,6 +102,14 @@ LDFLAGS += $(LDFLAGS-y) >> >> include Makefile >> >> +DEPS = .*.d >> +define gendep >> + ifneq ($(1),$(subst /,:,$(1))) >> + DEPS += $(dir $(1)).$(basename $(notdir $(1))).d >> + endif >> +endef >> +$(foreach o,$(filter-out %/,$(obj-y)),$(eval $(call gendep,$(o)))) > > Is this generating a .subdir.file.d for each subdir/file.o in obj-y? Actually a subdir/.file.d, but other than this minor difference - yes. > This is as a consequence of now building subdir/file.o from the parent > directory instead of recursing for some subset of files? Yes. > It seems quite inconsistent to me to have xen/arch/x86/x86_64/Makefile > building some files directly and xen/arch/x86/Makefile to be building > another subset of those files via x86_64/FOO.o. Even more so that other > than compat.o I can't see what makes many affected files (e.g. mm.o or > platform_hypercall.o) special in this regard. The platform_hypercall one is quite obvious, because x86_64/platform_hypercall.c just includes platform_hypercall.c (which is the general pattern we're dealing with here). For mm.c it was just prompted by actual collisions seen. > Does all of that fall out from a desire to reuse __FILE__? If so I'm > inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever > would seem likely to me to end up less strange (but maybe you tried that > and it was worse?). Yes to the first question. And no, I didn't try the alternative you suggest, but discarded it as the uglier variant from the beginning. In particular I dislike (parts of) file names to be specified on the command line, rather than getting derived from what we have anyway. Considering that Andrew was fine with the x86 parts, I'd want to change the approach (the x86 side of which I understand is of particular concern to you) only if you're convinced this alternative approach is sufficiently much better. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |