Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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