This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] x86: force out-of-line instances of inline funct

To: "Keir Fraser" <keir@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86: force out-of-line instances of inline functions into .init.text in init-only code
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 11 Mar 2011 17:02:35 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 11 Mar 2011 09:02:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9A00152.2B712%keir@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D7A5BFC0200007800035F0E@xxxxxxxxxxxxxxxxxx> <C9A00152.2B712%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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.


Xen-devel mailing list