>>> On 11.03.11 at 17:41, Keir Fraser <keir@xxxxxxx> wrote:
> On 11/03/2011 16:29, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>
>>> Isn't this a possible problem for any file compiled under the rules of
>>> obj-bin-y? If so, below should be defined for all such source files, perhaps
>>> -D a macro def on $CC command line in that case (e.g., some obvious textual
>>> macro name) and then pick up on that in <xen/compiler.h> to suitably
>>> re-define inline and always_inline (and explain why in a code comment).
>>
>> It's not tied to obj-bin-y, but rather to the .init.o rule, but yes, the
>> problem would possibly affect any such object. My problem is that
>> so far I wasn't able to think of a (clean and maintenance free) way
>> to force in a -D for those very files, since the compilation step is
>> the same as for "normal" .o-s. Hence, rather than waiting for
>> people to start asking what the resulting error message means, I
>> thought we should at least fix it in the place where the problem
>> was observed in reality (which happened to me when I put the
>> new bits on a system that I don't update that regularly).
>
> If we apply the hack it will never go away. If we can't come up with a clean
> maintenance-free way to get all files through the new check, the new check
> should be removed. Perhaps you could list the object files in a new
> obj-init-y list, which you then fold into obj-bin-y whilst also adding your
> .init suffix, and then also have an extra rule like:
> $(obj-init-y): CFLAGS += -DINIT_SECTIONS_ONLY
> Maybe that would work?
Yes. I thought about a $(filter %.init.o,$(obj-y)): doing the same
thing without needing two separate lists. I'll give this a try.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home