Xen devel - Mar 2011 - [PATCH] x86: force out-of-line instances of inline functions into .init.text in init-only code

Some compiler versions may choose to not inline certain functions,
but the check introduced in c/s 23003:768269c43914 and applying to
domain_build.o as of 23011:be7e54d86c57 wants .text to be empty.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

--- 2011-03-09.orig/xen/arch/x86/domain_build.c
+++ 2011-03-09/xen/arch/x86/domain_build.c
@@ -5,6 +5,7 @@
  */
 
 #include <xen/config.h>
+#define __inline__ __inline__ __init
 #include <xen/init.h>
 #include <xen/lib.h>
 #include <xen/ctype.h>




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/03/2011 16:08, "Jan Beulich" <JBeulich@novell.com> wrote:
> Some compiler versions may choose to not inline certain functions,
> but the check introduced in c/s 23003:768269c43914 and applying to
> domain_build.o as of 23011:be7e54d86c57 wants .text to be empty.
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).

 -- Keir
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
> 
> --- 2011-03-09.orig/xen/arch/x86/domain_build.c
> +++ 2011-03-09/xen/arch/x86/domain_build.c
> @@ -5,6 +5,7 @@
>   */
>  
>  #include <xen/config.h>
> +#define __inline__ __inline__ __init
>  #include <xen/init.h>
>  #include <xen/lib.h>
>  #include <xen/ctype.h>
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 11.03.11 at 17:16, Keir Fraser <keir@xen.org> wrote:
> On 11/03/2011 16:08, "Jan Beulich" <JBeulich@novell.com>
wrote:
> 
>> Some compiler versions may choose to not inline certain functions,
>> but the check introduced in c/s 23003:768269c43914 and applying to
>> domain_build.o as of 23011:be7e54d86c57 wants .text to be empty.
> 
> 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).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 11/03/2011 16:29, "Jan Beulich" <JBeulich@novell.com> 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?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> On 11.03.11 at 17:41, Keir Fraser <keir@xen.org> wrote:
> On 11/03/2011 16:29, "Jan Beulich" <JBeulich@novell.com>
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@lists.xensource.com
http://lists.xensource.com/xen-devel