[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v5 08/16] build: Introduce $(cpp_flags)



On 28.04.2020 16:01, Anthony PERARD wrote:
> On Thu, Apr 23, 2020 at 06:48:51PM +0200, Jan Beulich wrote:
>> On 21.04.2020 18:12, Anthony PERARD wrote:
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -123,6 +123,7 @@ $(obj-bin-y): XEN_CFLAGS := $(filter-out 
>>> -flto,$(XEN_CFLAGS))
>>>  
>>>  c_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_CFLAGS) 
>>> '-D__OBJECT_FILE__="$@"'
>>>  a_flags = -MMD -MP -MF $(@D)/.$(@F).d $(XEN_AFLAGS)
>>> +cpp_flags = $(filter-out -Wa$(comma)%,$(a_flags))
>>
>> I can see this happening to be this way right now, but in principle
>> I could see a_flags to hold items applicable to assembly files only,
>> but not to (the preprocessing of) C files. Hence while this is fine
>> for now, ...
>>
>>> @@ -207,7 +208,7 @@ quiet_cmd_cc_s_c = CC      $@
>>>  cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@
>>>  
>>>  quiet_cmd_s_S = CPP     $@
>>> -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@
>>> +cmd_s_S = $(CPP) $(cpp_flags) $< -o $@
>>
>> ... this one is a trap waiting for someone to fall in imo. Instead
>> where I'd expect this patch to use $(cpp_flags) is e.g. in
>> xen/arch/x86/mm/Makefile:
>>
>> guest_walk_%.i: guest_walk.c Makefile
>>      $(CPP) $(cpp_flags) -DGUEST_PAGING_LEVELS=$* -c $< -o $@
>>
>> And note how this currently uses $(c_flags), not $(a_flags), which
>> suggests that your deriving from $(a_flags) isn't correct either.
> 
> I think we can drop this patch for now, and change patch "xen/build:
> factorise generation of the linker scripts" to not use $(cpp_flags).
> 
> If we derive $(cpp_flags) from $(c_flags) instead, we would need to
> find out if CPP commands using a_flags can use c_flags instead.
> 
> On the other hand, I've looked at Linux source code, and they use
> $(cpp_flags) for only a few targets, only to generate the .lds scripts.
> For other rules, they use either a_flags or c_flags, for example:
>     %.i: %.c ; uses $(c_flags)
>     %.i: %.S ; uses $(a_flags)
>     %.s: %.S ; uses $(a_flags)

The first on really ought to be use cpp_flags. I couldn't find the
middle one. The last one clearly has to do something about -Wa,
options, but apart from this I'd consider a_flags appropriate to
use there.

> (Also, they use -Qunused-arguments clang's options, so they don't need
> to filter out -Wa,* arguments, I think.)

Maybe we should do so too then?

> So, maybe having a single $(cpp_flags) when running the CPP command
> isn't such a good idea.

Right - after all in particular the use of CPP to produce .lds is
an abuse, as the source file (named .lds.S) isn't really what its
name says.

> So, would dropping $(cpp_flags) for now, and rework the *FLAGS later, be
> good enough?

I don't think so, no, I'm sorry. cpp_flags should be there for its
real purpose. Whether the .lds.S -> .lds rule can use it, or should
use a_flags, or yet something else is a different thing.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.