[PATCH] xen: Don't use -nostdinc flags with CLANG

[PATCH] xen: Don't use -nostdinc flags with CLANG

[Julien Grall]

Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
compilation with clang:

In file included from sched_sedf.c:8:
In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
/home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
not found with <angled> include; use "quotes" instead
           ^~~~~~~~~~
           "stdarg.h"
In file included from sched_sedf.c:8:
/home/julieng/works/xen/xen/include/xen/lib.h:101:63: error: unknown type name 'va_list'
extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
                                                              ^
/home/julieng/works/xen/xen/include/xen/lib.h:105:64: error: unknown type name 'va_list'
extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)

I have the same errors on different version of clang:
    - clang 3.0 on debian wheezy
    - clang 3.3 on Fedora 20
    - clang 3.5 build from trunk

Removing -nostdinc fix the build on clang.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 xen/Rules.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index df1428f..ed9b8d0 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -46,7 +46,8 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 # Solaris puts stdarg.h &c in the system include directory.
 ifneq ($(XEN_OS),SunOS)
-CFLAGS += -nostdinc -iwithprefix include
+CFLAGS-y        += -iwithprefix include
+CFLAGS-$(gcc)   += -nostdinc
 endif
 
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
-- 
1.8.5.3

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Jan Beulich]

>>> On 11.02.14 at 00:29, Julien Grall <julien.grall@linaro.org> wrote:
> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
> compilation with clang:
> 
> In file included from sched_sedf.c:8:
> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' 
> file
> not found with <angled> include; use "quotes" instead
>            ^~~~~~~~~~
>            "stdarg.h"
> In file included from sched_sedf.c:8:
> /home/julieng/works/xen/xen/include/xen/lib.h:101:63: error: unknown type 
> name 'va_list'
> extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
>                                                               ^
> /home/julieng/works/xen/xen/include/xen/lib.h:105:64: error: unknown type 
> name 'va_list'
> extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
> 
> I have the same errors on different version of clang:
>     - clang 3.0 on debian wheezy
>     - clang 3.3 on Fedora 20
>     - clang 3.5 build from trunk
> 
> Removing -nostdinc fix the build on clang.

But does this also do the right thing? I.e. I doubt you're immune
then against picking up headers you don't want to include in a
hypervisor build, or properly failing if - for whatever reason, e.g.
during development after having made a mistake - a header can't
be found in the paths we want the compiler to look for them, but
can be found in a "standard" include directory.

IOW I think it first needs to be understood/explained why and by
how much clang behavior differs here.

Jan

> Signed-off-by: Julien Grall <julien.grall@linaro.org>
> ---
>  xen/Rules.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index df1428f..ed9b8d0 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -46,7 +46,8 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
>  CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
>  # Solaris puts stdarg.h &c in the system include directory.
>  ifneq ($(XEN_OS),SunOS)
> -CFLAGS += -nostdinc -iwithprefix include
> +CFLAGS-y        += -iwithprefix include
> +CFLAGS-$(gcc)   += -nostdinc
>  endif
>  
>  CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
> -- 
> 1.8.5.3
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Tim Deegan]

At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
> compilation with clang:
> 
> In file included from sched_sedf.c:8:
> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
> not found with <angled> include; use "quotes" instead
>            ^~~~~~~~~~
>            "stdarg.h"

Looks like on your system stdarg.h doesn't live in a compiler-specific
path, like we have for the BSDs.  I think we should just go to using
our own definitions for stdarg/stdbool everywhere; trying to chase the
compiler-specific versions around is a PITA, and the pieces we
actually need are trivial.

Tim.

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Julien Grall]

On 11/02/14 08:53, Tim Deegan wrote:
> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
>> compilation with clang:
>>
>> In file included from sched_sedf.c:8:
>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
>> not found with <angled> include; use "quotes" instead
>>             ^~~~~~~~~~
>>             "stdarg.h"
>
> Looks like on your system stdarg.h doesn't live in a compiler-specific
> path, like we have for the BSDs.  I think we should just go to using
> our own definitions for stdarg/stdbool everywhere; trying to chase the
> compiler-specific versions around is a PITA, and the pieces we
> actually need are trivial.

For BSDs, we are using our own stdargs/stdbool.  So we don't include the 
system <stdarg.h>.

Linux is using $(CC) -print-file-name=include to get the right path. It 
works with both gcc and clang on Linux distos, but not on FreeBSD.

-- 
Julien Grall

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Tim Deegan]

At 12:30 +0000 on 11 Feb (1392118227), Julien Grall wrote:
> 
> 
> On 11/02/14 08:53, Tim Deegan wrote:
> > At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
> >> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
> >> compilation with clang:
> >>
> >> In file included from sched_sedf.c:8:
> >> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
> >> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
> >> not found with <angled> include; use "quotes" instead
> >>             ^~~~~~~~~~
> >>             "stdarg.h"
> >
> > Looks like on your system stdarg.h doesn't live in a compiler-specific
> > path, like we have for the BSDs.  I think we should just go to using
> > our own definitions for stdarg/stdbool everywhere; trying to chase the
> > compiler-specific versions around is a PITA, and the pieces we
> > actually need are trivial.
> 
> For BSDs, we are using our own stdargs/stdbool.  So we don't include the 
> system <stdarg.h>.
> 
> Linux is using $(CC) -print-file-name=include to get the right path. It 
> works with both gcc and clang on Linux distos, but not on FreeBSD.

Wait - is the error message you posted from clang on FreeBSD?
That's surprising; on FreeBSD xen/stdarg.h shouldn't be trying to
include <stdarg.h> at all.  Is __FreeBSD__ not being defined?

Tim.

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Julien Grall]

On 11/02/14 12:35, Tim Deegan wrote:
> At 12:30 +0000 on 11 Feb (1392118227), Julien Grall wrote:
>>
>>
>> On 11/02/14 08:53, Tim Deegan wrote:
>>> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
>>>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
>>>> compilation with clang:
>>>>
>>>> In file included from sched_sedf.c:8:
>>>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
>>>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
>>>> not found with <angled> include; use "quotes" instead
>>>>              ^~~~~~~~~~
>>>>              "stdarg.h"
>>>
>>> Looks like on your system stdarg.h doesn't live in a compiler-specific
>>> path, like we have for the BSDs.  I think we should just go to using
>>> our own definitions for stdarg/stdbool everywhere; trying to chase the
>>> compiler-specific versions around is a PITA, and the pieces we
>>> actually need are trivial.
>>
>> For BSDs, we are using our own stdargs/stdbool.  So we don't include the
>> system <stdarg.h>.
>>
>> Linux is using $(CC) -print-file-name=include to get the right path. It
>> works with both gcc and clang on Linux distos, but not on FreeBSD.
>
> Wait - is the error message you posted from clang on FreeBSD?
> That's surprising; on FreeBSD xen/stdarg.h shouldn't be trying to
> include <stdarg.h> at all.  Is __FreeBSD__ not being defined?


No it's from Linux (Debian Wheezy and Fedora). I just gave a try to the 
"-print-file-name" solution on FreeBSD.

-- 
Julien Grall

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Tim Deegan]

At 12:36 +0000 on 11 Feb (1392118581), Julien Grall wrote:
> 
> 
> On 11/02/14 12:35, Tim Deegan wrote:
> > At 12:30 +0000 on 11 Feb (1392118227), Julien Grall wrote:
> >>
> >>
> >> On 11/02/14 08:53, Tim Deegan wrote:
> >>> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
> >>>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
> >>>> compilation with clang:
> >>>>
> >>>> In file included from sched_sedf.c:8:
> >>>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
> >>>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
> >>>> not found with <angled> include; use "quotes" instead
> >>>>              ^~~~~~~~~~
> >>>>              "stdarg.h"
> >>>
> >>> Looks like on your system stdarg.h doesn't live in a compiler-specific
> >>> path, like we have for the BSDs.  I think we should just go to using
> >>> our own definitions for stdarg/stdbool everywhere; trying to chase the
> >>> compiler-specific versions around is a PITA, and the pieces we
> >>> actually need are trivial.
> >>
> >> For BSDs, we are using our own stdargs/stdbool.  So we don't include the
> >> system <stdarg.h>.
> >>
> >> Linux is using $(CC) -print-file-name=include to get the right path. It
> >> works with both gcc and clang on Linux distos, but not on FreeBSD.
> >
> > Wait - is the error message you posted from clang on FreeBSD?
> > That's surprising; on FreeBSD xen/stdarg.h shouldn't be trying to
> > include <stdarg.h> at all.  Is __FreeBSD__ not being defined?
> 
> 
> No it's from Linux (Debian Wheezy and Fedora). I just gave a try to the 
> "-print-file-name" solution on FreeBSD.

Oh, OK.  Yeah, we knew that didn't work there, because on *BSD the
compiler-specific headers like stdarg.h actually live in /usr/include
and can themselves include other system headers.  That's why we have
our own implementation of the bits we need, that we use on BSD.

Are you using a very old version of clang?  As 06a9c7e points out,
our current runes didn't work before clang v3.0.

If not, rather than chasing this around any further, I think we should
abandon trying to use the compiler-provided headers even on linux.
Does this patch fix your build issue?

commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
Author: Tim Deegan <tim@xen.org>
Date:   Tue Feb 11 12:44:09 2014 +0000

    xen: stop trying to use the system <stdarg.h> and <stdbool.h>
    
    We already have our own versions of the stdarg/stdbool definitions, for
    systems where those headers are installed in /usr/include.
    
    On linux, they're typically installed in compiler-specific paths, but
    finding them has proved unreliable.  Drop that and use our own versions
    everywhere.
    
    Signed-off-by: Tim Deegan <tim@xen.org>

diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
index d1b2540..0283f06 100644
--- a/xen/include/xen/stdarg.h
+++ b/xen/include/xen/stdarg.h
@@ -1,23 +1,21 @@
 #ifndef __XEN_STDARG_H__
 #define __XEN_STDARG_H__
 
-#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
-   typedef __builtin_va_list va_list;
-#  ifdef __GNUC__
-#    define __GNUC_PREREQ__(x, y)                                       \
-        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
-         (__GNUC__ > (x)))
-#  else
-#    define __GNUC_PREREQ__(x, y)   0
-#  endif
-#  if !__GNUC_PREREQ__(4, 5)
-#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
-#  endif
-#  define va_start(ap, last)    __builtin_va_start((ap), (last))
-#  define va_end(ap)            __builtin_va_end(ap)
-#  define va_arg                __builtin_va_arg
+#ifdef __GNUC__
+#  define __GNUC_PREREQ__(x, y)                                       \
+      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
+       (__GNUC__ > (x)))
 #else
-#  include <stdarg.h>
+#  define __GNUC_PREREQ__(x, y)   0
 #endif
 
+#if !__GNUC_PREREQ__(4, 5)
+#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#endif
+
+typedef __builtin_va_list va_list;
+#define va_start(ap, last)    __builtin_va_start((ap), (last))
+#define va_end(ap)            __builtin_va_end(ap)
+#define va_arg                __builtin_va_arg
+
 #endif /* __XEN_STDARG_H__ */
diff --git a/xen/include/xen/stdbool.h b/xen/include/xen/stdbool.h
index f0faedf..b0947a6 100644
--- a/xen/include/xen/stdbool.h
+++ b/xen/include/xen/stdbool.h
@@ -1,13 +1,9 @@
 #ifndef __XEN_STDBOOL_H__
 #define __XEN_STDBOOL_H__
 
-#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
-#  define bool _Bool
-#  define true 1
-#  define false 0
-#  define __bool_true_false_are_defined   1
-#else
-#  include <stdbool.h>
-#endif
+#define bool _Bool
+#define true 1
+#define false 0
+#define __bool_true_false_are_defined   1
 
 #endif /* __XEN_STDBOOL_H__ */

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Julien Grall]

On 11/02/14 12:59, Tim Deegan wrote:
> Are you using a very old version of clang?  As 06a9c7e points out,
> our current runes didn't work before clang v3.0.

I'm using clang 3.5 (which have other issue to compile Xen), but I have 
also tried 3.0 and 3.3.

> If not, rather than chasing this around any further, I think we should
> abandon trying to use the compiler-provided headers even on linux.
> Does this patch fix your build issue?
>
> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
> Author: Tim Deegan <tim@xen.org>
> Date:   Tue Feb 11 12:44:09 2014 +0000
>
>      xen: stop trying to use the system <stdarg.h> and <stdbool.h>

With this patch, -iwithprefix include is not necessary now. I wondering 
if we can remove it from the command line.

>      We already have our own versions of the stdarg/stdbool definitions, for
>      systems where those headers are installed in /usr/include.
>
>      On linux, they're typically installed in compiler-specific paths, but
>      finding them has proved unreliable.  Drop that and use our own versions
>      everywhere.
>
>      Signed-off-by: Tim Deegan <tim@xen.org>

This patch is working fine to build xen clang 3.0, 3.3.
I have others issue to build with clang 3.5.

Tested-by: Julien Grall <julien.grall@linaro.org>

Thanks!

-- 
Julien Grall

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Julien Grall]

On 11/02/14 12:59, Tim Deegan wrote:
> At 12:36 +0000 on 11 Feb (1392118581), Julien Grall wrote:
>>
>>
>> On 11/02/14 12:35, Tim Deegan wrote:
>>> At 12:30 +0000 on 11 Feb (1392118227), Julien Grall wrote:
>>>>
>>>>
>>>> On 11/02/14 08:53, Tim Deegan wrote:
>>>>> At 23:29 +0000 on 10 Feb (1392071374), Julien Grall wrote:
>>>>>> Commit 06a9c7e "xen: move -nostdinc into common Rules.mk." breaks
>>>>>> compilation with clang:
>>>>>>
>>>>>> In file included from sched_sedf.c:8:
>>>>>> In file included from /home/julieng/works/xen/xen/include/xen/lib.h:5:
>>>>>> /home/julieng/works/xen/xen/include/xen/stdarg.h:20:12: error: 'stdarg.h' file
>>>>>> not found with <angled> include; use "quotes" instead
>>>>>>               ^~~~~~~~~~
>>>>>>               "stdarg.h"
>>>>>
>>>>> Looks like on your system stdarg.h doesn't live in a compiler-specific
>>>>> path, like we have for the BSDs.  I think we should just go to using
>>>>> our own definitions for stdarg/stdbool everywhere; trying to chase the
>>>>> compiler-specific versions around is a PITA, and the pieces we
>>>>> actually need are trivial.
>>>>
>>>> For BSDs, we are using our own stdargs/stdbool.  So we don't include the
>>>> system <stdarg.h>.
>>>>
>>>> Linux is using $(CC) -print-file-name=include to get the right path. It
>>>> works with both gcc and clang on Linux distos, but not on FreeBSD.
>>>
>>> Wait - is the error message you posted from clang on FreeBSD?
>>> That's surprising; on FreeBSD xen/stdarg.h shouldn't be trying to
>>> include <stdarg.h> at all.  Is __FreeBSD__ not being defined?
>>
>>
>> No it's from Linux (Debian Wheezy and Fedora). I just gave a try to the
>> "-print-file-name" solution on FreeBSD.
>
> Oh, OK.  Yeah, we knew that didn't work there, because on *BSD the
> compiler-specific headers like stdarg.h actually live in /usr/include
> and can themselves include other system headers.  That's why we have
> our own implementation of the bits we need, that we use on BSD.
>
> Are you using a very old version of clang?  As 06a9c7e points out,
> our current runes didn't work before clang v3.0.
>
> If not, rather than chasing this around any further, I think we should
> abandon trying to use the compiler-provided headers even on linux.
> Does this patch fix your build issue?
>
> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
> Author: Tim Deegan <tim@xen.org>
> Date:   Tue Feb 11 12:44:09 2014 +0000
>
>      xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>
>      We already have our own versions of the stdarg/stdbool definitions, for
>      systems where those headers are installed in /usr/include.
>
>      On linux, they're typically installed in compiler-specific paths, but
>      finding them has proved unreliable.  Drop that and use our own versions
>      everywhere.
>
>      Signed-off-by: Tim Deegan <tim@xen.org>
>
> diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
> index d1b2540..0283f06 100644
> --- a/xen/include/xen/stdarg.h
> +++ b/xen/include/xen/stdarg.h
> @@ -1,23 +1,21 @@
>   #ifndef __XEN_STDARG_H__
>   #define __XEN_STDARG_H__
>
> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
> -   typedef __builtin_va_list va_list;
> -#  ifdef __GNUC__
> -#    define __GNUC_PREREQ__(x, y)                                       \
> -        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
> -         (__GNUC__ > (x)))
> -#  else
> -#    define __GNUC_PREREQ__(x, y)   0
> -#  endif
> -#  if !__GNUC_PREREQ__(4, 5)
> -#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
> -#  endif
> -#  define va_start(ap, last)    __builtin_va_start((ap), (last))
> -#  define va_end(ap)            __builtin_va_end(ap)
> -#  define va_arg                __builtin_va_arg
> +#ifdef __GNUC__
> +#  define __GNUC_PREREQ__(x, y)                                       \
> +      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
> +       (__GNUC__ > (x)))
>   #else
> -#  include <stdarg.h>
> +#  define __GNUC_PREREQ__(x, y)   0
>   #endif
>
> +#if !__GNUC_PREREQ__(4, 5)
> +#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
> +#endif
> +
> +typedef __builtin_va_list va_list;
> +#define va_start(ap, last)    __builtin_va_start((ap), (last))
> +#define va_end(ap)            __builtin_va_end(ap)
> +#define va_arg                __builtin_va_arg
> +
>   #endif /* __XEN_STDARG_H__ */
> diff --git a/xen/include/xen/stdbool.h b/xen/include/xen/stdbool.h
> index f0faedf..b0947a6 100644
> --- a/xen/include/xen/stdbool.h
> +++ b/xen/include/xen/stdbool.h
> @@ -1,13 +1,9 @@
>   #ifndef __XEN_STDBOOL_H__
>   #define __XEN_STDBOOL_H__
>
> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
> -#  define bool _Bool
> -#  define true 1
> -#  define false 0
> -#  define __bool_true_false_are_defined   1
> -#else
> -#  include <stdbool.h>
> -#endif
> +#define bool _Bool
> +#define true 1
> +#define false 0
> +#define __bool_true_false_are_defined   1
>
>   #endif /* __XEN_STDBOOL_H__ */
>

-- 
Julien Grall

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Tim Deegan]

At 13:20 +0000 on 11 Feb (1392121252), Julien Grall wrote:
> 
> 
> On 11/02/14 12:59, Tim Deegan wrote:
> > Are you using a very old version of clang?  As 06a9c7e points out,
> > our current runes didn't work before clang v3.0.
> 
> I'm using clang 3.5 (which have other issue to compile Xen), but I have 
> also tried 3.0 and 3.3.
> 
> > If not, rather than chasing this around any further, I think we should
> > abandon trying to use the compiler-provided headers even on linux.
> > Does this patch fix your build issue?
> >
> > commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
> > Author: Tim Deegan <tim@xen.org>
> > Date:   Tue Feb 11 12:44:09 2014 +0000
> >
> >      xen: stop trying to use the system <stdarg.h> and <stdbool.h>
> 
> With this patch, -iwithprefix include is not necessary now. I wondering 
> if we can remove it from the command line.

Yes, I think so.

> >      We already have our own versions of the stdarg/stdbool definitions, for
> >      systems where those headers are installed in /usr/include.
> >
> >      On linux, they're typically installed in compiler-specific paths, but
> >      finding them has proved unreliable.  Drop that and use our own versions
> >      everywhere.
> >
> >      Signed-off-by: Tim Deegan <tim@xen.org>
> 
> This patch is working fine to build xen clang 3.0, 3.3.
> I have others issue to build with clang 3.5.
> 
> Tested-by: Julien Grall <julien.grall@linaro.org>

Great!  Assuming you'll have a series of patches to fix the clang-3.5
build, do you want to just take this into that series, and drop the
-iwithprefix at the same time?

Cheers,

Tim.

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Julien Grall]

(Add George as release manager)

On 11/02/14 13:59, Tim Deegan wrote:
> At 13:20 +0000 on 11 Feb (1392121252), Julien Grall wrote:
>>
>>
>> On 11/02/14 12:59, Tim Deegan wrote:
>>> Are you using a very old version of clang?  As 06a9c7e points out,
>>> our current runes didn't work before clang v3.0.
>>
>> I'm using clang 3.5 (which have other issue to compile Xen), but I have
>> also tried 3.0 and 3.3.
>>
>>> If not, rather than chasing this around any further, I think we should
>>> abandon trying to use the compiler-provided headers even on linux.
>>> Does this patch fix your build issue?
>>>
>>> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
>>> Author: Tim Deegan <tim@xen.org>
>>> Date:   Tue Feb 11 12:44:09 2014 +0000
>>>
>>>       xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>>
>> With this patch, -iwithprefix include is not necessary now. I wondering
>> if we can remove it from the command line.
>
> Yes, I think so.
>
>>>       We already have our own versions of the stdarg/stdbool definitions, for
>>>       systems where those headers are installed in /usr/include.
>>>
>>>       On linux, they're typically installed in compiler-specific paths, but
>>>       finding them has proved unreliable.  Drop that and use our own versions
>>>       everywhere.
>>>
>>>       Signed-off-by: Tim Deegan <tim@xen.org>
>>
>> This patch is working fine to build xen clang 3.0, 3.3.
>> I have others issue to build with clang 3.5.
>>
>> Tested-by: Julien Grall <julien.grall@linaro.org>
>
> Great!  Assuming you'll have a series of patches to fix the clang-3.5
> build, do you want to just take this into that series, and drop the
> -iwithprefix at the same time?

If it's possible I'd like this patch goes in Xen 4.4 to fix build with 
official version of clang (until 3.4).

Clang 3.5 is still under development, so I don't think it's important to 
have support for it in Xen 4.4.

Cheers,

-- 
Julien Grall

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Tim Deegan]

At 14:24 +0000 on 11 Feb (1392125052), Julien Grall wrote:
> (Add George as release manager)
> 
> On 11/02/14 13:59, Tim Deegan wrote:
> > At 13:20 +0000 on 11 Feb (1392121252), Julien Grall wrote:
> >>
> >>
> >> On 11/02/14 12:59, Tim Deegan wrote:
> >>> Are you using a very old version of clang?  As 06a9c7e points out,
> >>> our current runes didn't work before clang v3.0.
> >>
> >> I'm using clang 3.5 (which have other issue to compile Xen), but I have
> >> also tried 3.0 and 3.3.
> >>
> >>> If not, rather than chasing this around any further, I think we should
> >>> abandon trying to use the compiler-provided headers even on linux.
> >>> Does this patch fix your build issue?
> >>>
> >>> commit e7003f174e0df9192dde6fa8d33b0a20f99ce053
> >>> Author: Tim Deegan <tim@xen.org>
> >>> Date:   Tue Feb 11 12:44:09 2014 +0000
> >>>
> >>>       xen: stop trying to use the system <stdarg.h> and <stdbool.h>
> >>
> >> With this patch, -iwithprefix include is not necessary now. I wondering
> >> if we can remove it from the command line.
> >
> > Yes, I think so.
> >
> >>>       We already have our own versions of the stdarg/stdbool definitions, for
> >>>       systems where those headers are installed in /usr/include.
> >>>
> >>>       On linux, they're typically installed in compiler-specific paths, but
> >>>       finding them has proved unreliable.  Drop that and use our own versions
> >>>       everywhere.
> >>>
> >>>       Signed-off-by: Tim Deegan <tim@xen.org>
> >>
> >> This patch is working fine to build xen clang 3.0, 3.3.
> >> I have others issue to build with clang 3.5.
> >>
> >> Tested-by: Julien Grall <julien.grall@linaro.org>
> >
> > Great!  Assuming you'll have a series of patches to fix the clang-3.5
> > build, do you want to just take this into that series, and drop the
> > -iwithprefix at the same time?
> 
> If it's possible I'd like this patch goes in Xen 4.4 to fix build with 
> official version of clang (until 3.4).
> 
> Clang 3.5 is still under development, so I don't think it's important to 
> have support for it in Xen 4.4.

Fair enough.  In that case it needs a release ack from George.  It:
 - fixes a compile issue on some version s of clang;
 - might cause a regression with other compilers, but the regression
   is likely to be obvious (i.e. a compile-time failure).

And it needs an ack from Keir, for changing common code. 

v2 is below, removing "-iwithprefix".  I've kept your tested-by; hope
that's OK.

Cheers,

Tim.

commit 1d62fcb9ad8d2b409ac2cf0e8a3824e19ca3313f
Author: Tim Deegan <tim@xen.org>
Date:   Tue Feb 11 12:44:09 2014 +0000

    xen: stop trying to use the system <stdarg.h> and <stdbool.h>
    
    We already have our own versions of the stdarg/stdbool definitions, for
    systems where those headers are installed in /usr/include.
    
    On linux, they're typically installed in compiler-specific paths, but
    finding them has proved unreliable.  Drop that and use our own versions
    everywhere.
    
    Signed-off-by: Tim Deegan <tim@xen.org>
    Tested-by: Julien Grall <julien.grall@linaro.org>

diff --git a/xen/Rules.mk b/xen/Rules.mk
index df1428f..3a6cec5 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -44,10 +44,7 @@ ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
 CFLAGS += -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
-# Solaris puts stdarg.h &c in the system include directory.
-ifneq ($(XEN_OS),SunOS)
-CFLAGS += -nostdinc -iwithprefix include
-endif
+CFLAGS += -nostdinc
 
 CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
 CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c
diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
index d1b2540..0283f06 100644
--- a/xen/include/xen/stdarg.h
+++ b/xen/include/xen/stdarg.h
@@ -1,23 +1,21 @@
 #ifndef __XEN_STDARG_H__
 #define __XEN_STDARG_H__
 
-#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
-   typedef __builtin_va_list va_list;
-#  ifdef __GNUC__
-#    define __GNUC_PREREQ__(x, y)                                       \
-        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
-         (__GNUC__ > (x)))
-#  else
-#    define __GNUC_PREREQ__(x, y)   0
-#  endif
-#  if !__GNUC_PREREQ__(4, 5)
-#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
-#  endif
-#  define va_start(ap, last)    __builtin_va_start((ap), (last))
-#  define va_end(ap)            __builtin_va_end(ap)
-#  define va_arg                __builtin_va_arg
+#ifdef __GNUC__
+#  define __GNUC_PREREQ__(x, y)                                       \
+      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
+       (__GNUC__ > (x)))
 #else
-#  include <stdarg.h>
+#  define __GNUC_PREREQ__(x, y)   0
 #endif
 
+#if !__GNUC_PREREQ__(4, 5)
+#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
+#endif
+
+typedef __builtin_va_list va_list;
+#define va_start(ap, last)    __builtin_va_start((ap), (last))
+#define va_end(ap)            __builtin_va_end(ap)
+#define va_arg                __builtin_va_arg
+
 #endif /* __XEN_STDARG_H__ */
diff --git a/xen/include/xen/stdbool.h b/xen/include/xen/stdbool.h
index f0faedf..b0947a6 100644
--- a/xen/include/xen/stdbool.h
+++ b/xen/include/xen/stdbool.h
@@ -1,13 +1,9 @@
 #ifndef __XEN_STDBOOL_H__
 #define __XEN_STDBOOL_H__
 
-#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
-#  define bool _Bool
-#  define true 1
-#  define false 0
-#  define __bool_true_false_are_defined   1
-#else
-#  include <stdbool.h>
-#endif
+#define bool _Bool
+#define true 1
+#define false 0
+#define __bool_true_false_are_defined   1
 
 #endif /* __XEN_STDBOOL_H__ */

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Keir Fraser]

On 11/02/2014 14:33, "Tim Deegan" <tim@xen.org> wrote:

> Fair enough.  In that case it needs a release ack from George.  It:
>  - fixes a compile issue on some version s of clang;
>  - might cause a regression with other compilers, but the regression
>    is likely to be obvious (i.e. a compile-time failure).
> 
> And it needs an ack from Keir, for changing common code.
> 
> v2 is below, removing "-iwithprefix".  I've kept your tested-by; hope
> that's OK.
> 
> Cheers,
> 
> Tim.
> 
> commit 1d62fcb9ad8d2b409ac2cf0e8a3824e19ca3313f
> Author: Tim Deegan <tim@xen.org>
> Date:   Tue Feb 11 12:44:09 2014 +0000
> 
>     xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>     
>     We already have our own versions of the stdarg/stdbool definitions, for
>     systems where those headers are installed in /usr/include.
>     
>     On linux, they're typically installed in compiler-specific paths, but
>     finding them has proved unreliable.  Drop that and use our own versions
>     everywhere.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>
>     Tested-by: Julien Grall <julien.grall@linaro.org>

I'm fine with the principle of it. I don't know about how risky it is for
4.4.

Acked-by: Keir Fraser <keir@xen.org>

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[Tim Deegan]

George: ping.

At 15:33 +0100 on 11 Feb (1392129226), Tim Deegan wrote:
> At 14:24 +0000 on 11 Feb (1392125052), Julien Grall wrote:
> > If it's possible I'd like this patch goes in Xen 4.4 to fix build with 
> > official version of clang (until 3.4).
> > 
> > Clang 3.5 is still under development, so I don't think it's important to 
> > have support for it in Xen 4.4.
> 
> Fair enough.  In that case it needs a release ack from George.  It:
>  - fixes a compile issue on some version s of clang;
>  - might cause a regression with other compilers, but the regression
>    is likely to be obvious (i.e. a compile-time failure).
> 
> And it needs an ack from Keir, for changing common code. 
> 
> v2 is below, removing "-iwithprefix".  I've kept your tested-by; hope
> that's OK.
> 
> Cheers,
> 
> Tim.
> 
> commit 1d62fcb9ad8d2b409ac2cf0e8a3824e19ca3313f
> Author: Tim Deegan <tim@xen.org>
> Date:   Tue Feb 11 12:44:09 2014 +0000
> 
>     xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>     
>     We already have our own versions of the stdarg/stdbool definitions, for
>     systems where those headers are installed in /usr/include.
>     
>     On linux, they're typically installed in compiler-specific paths, but
>     finding them has proved unreliable.  Drop that and use our own versions
>     everywhere.
>     
>     Signed-off-by: Tim Deegan <tim@xen.org>
>     Tested-by: Julien Grall <julien.grall@linaro.org>
> 
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index df1428f..3a6cec5 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -44,10 +44,7 @@ ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
>  CFLAGS += -fno-builtin -fno-common
>  CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
>  CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
> -# Solaris puts stdarg.h &c in the system include directory.
> -ifneq ($(XEN_OS),SunOS)
> -CFLAGS += -nostdinc -iwithprefix include
> -endif
> +CFLAGS += -nostdinc
>  
>  CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
>  CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c
> diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
> index d1b2540..0283f06 100644
> --- a/xen/include/xen/stdarg.h
> +++ b/xen/include/xen/stdarg.h
> @@ -1,23 +1,21 @@
>  #ifndef __XEN_STDARG_H__
>  #define __XEN_STDARG_H__
>  
> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
> -   typedef __builtin_va_list va_list;
> -#  ifdef __GNUC__
> -#    define __GNUC_PREREQ__(x, y)                                       \
> -        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
> -         (__GNUC__ > (x)))
> -#  else
> -#    define __GNUC_PREREQ__(x, y)   0
> -#  endif
> -#  if !__GNUC_PREREQ__(4, 5)
> -#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
> -#  endif
> -#  define va_start(ap, last)    __builtin_va_start((ap), (last))
> -#  define va_end(ap)            __builtin_va_end(ap)
> -#  define va_arg                __builtin_va_arg
> +#ifdef __GNUC__
> +#  define __GNUC_PREREQ__(x, y)                                       \
> +      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
> +       (__GNUC__ > (x)))
>  #else
> -#  include <stdarg.h>
> +#  define __GNUC_PREREQ__(x, y)   0
>  #endif
>  
> +#if !__GNUC_PREREQ__(4, 5)
> +#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
> +#endif
> +
> +typedef __builtin_va_list va_list;
> +#define va_start(ap, last)    __builtin_va_start((ap), (last))
> +#define va_end(ap)            __builtin_va_end(ap)
> +#define va_arg                __builtin_va_arg
> +
>  #endif /* __XEN_STDARG_H__ */
> diff --git a/xen/include/xen/stdbool.h b/xen/include/xen/stdbool.h
> index f0faedf..b0947a6 100644
> --- a/xen/include/xen/stdbool.h
> +++ b/xen/include/xen/stdbool.h
> @@ -1,13 +1,9 @@
>  #ifndef __XEN_STDBOOL_H__
>  #define __XEN_STDBOOL_H__
>  
> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
> -#  define bool _Bool
> -#  define true 1
> -#  define false 0
> -#  define __bool_true_false_are_defined   1
> -#else
> -#  include <stdbool.h>
> -#endif
> +#define bool _Bool
> +#define true 1
> +#define false 0
> +#define __bool_true_false_are_defined   1
>  
>  #endif /* __XEN_STDBOOL_H__ */
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[George Dunlap]

On 02/13/2014 11:24 AM, Tim Deegan wrote:
> George: ping.
>
> At 15:33 +0100 on 11 Feb (1392129226), Tim Deegan wrote:
>> At 14:24 +0000 on 11 Feb (1392125052), Julien Grall wrote:
>>> If it's possible I'd like this patch goes in Xen 4.4 to fix build with
>>> official version of clang (until 3.4).
>>>
>>> Clang 3.5 is still under development, so I don't think it's important to
>>> have support for it in Xen 4.4.
>> Fair enough.  In that case it needs a release ack from George.  It:
>>   - fixes a compile issue on some version s of clang;
>>   - might cause a regression with other compilers, but the regression
>>     is likely to be obvious (i.e. a compile-time failure).

So the main risk would be if stgarg.h contained something like the 
"__GNUC_PREREQ__(4, 5)" #ifdef-ery that we missed.  Without this patch, 
we know it doesn't compile on the latest version of clang.  I think 
that's probably worse than the risk of potentially not compiling on some 
compiler that doesn't end up being tested before the release:

Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>


>>
>> And it needs an ack from Keir, for changing common code.
>>
>> v2 is below, removing "-iwithprefix".  I've kept your tested-by; hope
>> that's OK.
>>
>> Cheers,
>>
>> Tim.
>>
>> commit 1d62fcb9ad8d2b409ac2cf0e8a3824e19ca3313f
>> Author: Tim Deegan <tim@xen.org>
>> Date:   Tue Feb 11 12:44:09 2014 +0000
>>
>>      xen: stop trying to use the system <stdarg.h> and <stdbool.h>
>>      
>>      We already have our own versions of the stdarg/stdbool definitions, for
>>      systems where those headers are installed in /usr/include.
>>      
>>      On linux, they're typically installed in compiler-specific paths, but
>>      finding them has proved unreliable.  Drop that and use our own versions
>>      everywhere.
>>      
>>      Signed-off-by: Tim Deegan <tim@xen.org>
>>      Tested-by: Julien Grall <julien.grall@linaro.org>
>>
>> diff --git a/xen/Rules.mk b/xen/Rules.mk
>> index df1428f..3a6cec5 100644
>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -44,10 +44,7 @@ ALL_OBJS-$(x86)          += $(BASEDIR)/crypto/built_in.o
>>   CFLAGS += -fno-builtin -fno-common
>>   CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
>>   CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
>> -# Solaris puts stdarg.h &c in the system include directory.
>> -ifneq ($(XEN_OS),SunOS)
>> -CFLAGS += -nostdinc -iwithprefix include
>> -endif
>> +CFLAGS += -nostdinc
>>   
>>   CFLAGS-$(XSM_ENABLE)    += -DXSM_ENABLE
>>   CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE -DXSM_MAGIC=0xf97cff8c
>> diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
>> index d1b2540..0283f06 100644
>> --- a/xen/include/xen/stdarg.h
>> +++ b/xen/include/xen/stdarg.h
>> @@ -1,23 +1,21 @@
>>   #ifndef __XEN_STDARG_H__
>>   #define __XEN_STDARG_H__
>>   
>> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
>> -   typedef __builtin_va_list va_list;
>> -#  ifdef __GNUC__
>> -#    define __GNUC_PREREQ__(x, y)                                       \
>> -        ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
>> -         (__GNUC__ > (x)))
>> -#  else
>> -#    define __GNUC_PREREQ__(x, y)   0
>> -#  endif
>> -#  if !__GNUC_PREREQ__(4, 5)
>> -#    define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
>> -#  endif
>> -#  define va_start(ap, last)    __builtin_va_start((ap), (last))
>> -#  define va_end(ap)            __builtin_va_end(ap)
>> -#  define va_arg                __builtin_va_arg
>> +#ifdef __GNUC__
>> +#  define __GNUC_PREREQ__(x, y)                                       \
>> +      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
>> +       (__GNUC__ > (x)))
>>   #else
>> -#  include <stdarg.h>
>> +#  define __GNUC_PREREQ__(x, y)   0
>>   #endif
>>   
>> +#if !__GNUC_PREREQ__(4, 5)
>> +#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
>> +#endif
>> +
>> +typedef __builtin_va_list va_list;
>> +#define va_start(ap, last)    __builtin_va_start((ap), (last))
>> +#define va_end(ap)            __builtin_va_end(ap)
>> +#define va_arg                __builtin_va_arg
>> +
>>   #endif /* __XEN_STDARG_H__ */
>> diff --git a/xen/include/xen/stdbool.h b/xen/include/xen/stdbool.h
>> index f0faedf..b0947a6 100644
>> --- a/xen/include/xen/stdbool.h
>> +++ b/xen/include/xen/stdbool.h
>> @@ -1,13 +1,9 @@
>>   #ifndef __XEN_STDBOOL_H__
>>   #define __XEN_STDBOOL_H__
>>   
>> -#if defined(__OpenBSD__) || defined(__NetBSD__) || defined(__FreeBSD__)
>> -#  define bool _Bool
>> -#  define true 1
>> -#  define false 0
>> -#  define __bool_true_false_are_defined   1
>> -#else
>> -#  include <stdbool.h>
>> -#endif
>> +#define bool _Bool
>> +#define true 1
>> +#define false 0
>> +#define __bool_true_false_are_defined   1
>>   
>>   #endif /* __XEN_STDBOOL_H__ */
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel

Re: [PATCH] xen: Don't use -nostdinc flags with CLANG

[George Dunlap]

On 02/13/2014 11:46 AM, George Dunlap wrote:
> On 02/13/2014 11:24 AM, Tim Deegan wrote:
>> George: ping.
>>
>> At 15:33 +0100 on 11 Feb (1392129226), Tim Deegan wrote:
>>> At 14:24 +0000 on 11 Feb (1392125052), Julien Grall wrote:
>>>> If it's possible I'd like this patch goes in Xen 4.4 to fix build with
>>>> official version of clang (until 3.4).
>>>>
>>>> Clang 3.5 is still under development, so I don't think it's 
>>>> important to
>>>> have support for it in Xen 4.4.
>>> Fair enough.  In that case it needs a release ack from George.  It:
>>>   - fixes a compile issue on some version s of clang;
>>>   - might cause a regression with other compilers, but the regression
>>>     is likely to be obvious (i.e. a compile-time failure).
>
> So the main risk would be if stgarg.h contained something like the 
> "__GNUC_PREREQ__(4, 5)" #ifdef-ery that we missed.

Sorry, realized the grammar was ambiguous here.  For the record, I 
meant, the risk would be a system where the stdarg.h contained something 
of that type that our own copy didn't.

-G

[PATCH] xen: Don't use __builtin_stdarg_start().

[Tim Deegan]

Cset fca49a00 ("netbsd: build fix with gcc 4.5") changed the
definition of va_start() to use __builtin_va_start() rather than
__builtin_stdarg_start() for GCCs >= 4.5, but in fact GCC dropped
__builtin_stdarg_start() before v3.3.
    
Signed-off-by: Tim Deegan <tim@xen.org>

---

George: this should fix the build issues Roger was having with GCC 4.5
after my last stdarg patch.

diff --git a/xen/include/xen/stdarg.h b/xen/include/xen/stdarg.h
index 0283f06..216fe6d 100644
--- a/xen/include/xen/stdarg.h
+++ b/xen/include/xen/stdarg.h
@@ -1,18 +1,6 @@
 #ifndef __XEN_STDARG_H__
 #define __XEN_STDARG_H__
 
-#ifdef __GNUC__
-#  define __GNUC_PREREQ__(x, y)                                       \
-      ((__GNUC__ == (x) && __GNUC_MINOR__ >= (y)) ||                  \
-       (__GNUC__ > (x)))
-#else
-#  define __GNUC_PREREQ__(x, y)   0
-#endif
-
-#if !__GNUC_PREREQ__(4, 5)
-#  define __builtin_va_start(ap, last)    __builtin_stdarg_start((ap), (last))
-#endif
-
 typedef __builtin_va_list va_list;
 #define va_start(ap, last)    __builtin_va_start((ap), (last))
 #define va_end(ap)            __builtin_va_end(ap)

Re: [PATCH] xen: Don't use __builtin_stdarg_start().

[George Dunlap]

On 02/13/2014 03:19 PM, Tim Deegan wrote:
> Cset fca49a00 ("netbsd: build fix with gcc 4.5") changed the
> definition of va_start() to use __builtin_va_start() rather than
> __builtin_stdarg_start() for GCCs >= 4.5, but in fact GCC dropped
> __builtin_stdarg_start() before v3.3.
>      
> Signed-off-by: Tim Deegan <tim@xen.org>
>
> ---
>
> George: this should fix the build issues Roger was having with GCC 4.5
> after my last stdarg patch.

Once it has Roger's tested-by:

Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>

Re: [PATCH] xen: Don't use __builtin_stdarg_start().

[Roger Pau Monné]

On 13/02/14 16:19, Tim Deegan wrote:
> Cset fca49a00 ("netbsd: build fix with gcc 4.5") changed the
> definition of va_start() to use __builtin_va_start() rather than
> __builtin_stdarg_start() for GCCs >= 4.5, but in fact GCC dropped
> __builtin_stdarg_start() before v3.3.
>     
> Signed-off-by: Tim Deegan <tim@xen.org>

Tested-by: Roger Pau Monné <roger.pau@citrix.com>
With gcc version 4.4.5 (Debian 4.4.5-8)