From: Christoph Egger <Christoph.Egger@amd.com>
To: Keir Fraser <keir@xen.org>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH] xen: Deal with stdarg.h and -nostdinc
Date: Fri, 27 May 2011 11:48:15 +0200 [thread overview]
Message-ID: <4DDF735F.9020706@amd.com> (raw)
In-Reply-To: <CA052B9C.2DB31%keir@xen.org>
On 05/27/11 11:21, Keir Fraser wrote:
> On 27/05/2011 08:55, "Christoph Egger"<Christoph.Egger@amd.com> wrote:
>
>>> This stuff can be moderately fragile, and we've now had no actual bug
>>> reports about it in a long while.
>>
>> Here is a full error message:
>
> Ah, okay, actually I see our stdarg support is a bit inconsistent already.
> How about the attached alternative fix? A few notes about it:
>
> Firstly, in xen/stdarg.h I handle NetBSD the same as OpenBSD -- I go and
> grab /usr/include/stdarg.h directly. I don't know if that is really better
> than including the compiler intrinsics directly as you did. If you prefer we
> could do that instead, but whichever I think it makes sense to do the same
> for both BSD variants.
No, the assumption what works for one BSD works for all BSDs is wrong.
In the NetBSD case I get the error
that <machine/ansi.h> and <sys/featuretest.h> are not found.
That way <stdarg.h> pulls in machine specific definitions on NetBSD.
>
> Secondly, I wonder whether *BSD would be happier if we did not include
> -nostdinc on the command line? See arch/x86/Rules.mk where SunOS is already
> special cased. I don't know whether that would work for BSD too.
It works for NetBSD at least.
> Finally, rather than referencing a hardcoded /usr/include path or including
> gcc intrinsics in xen/stdarg.h, would *BSD prefer a -isystem command-line
> option to include the gcc headers in the search path? Then we could perhaps
> even get rid of xen/stdarg.h completely.
NetBSD is about to add clang/llvm support. If -isystem works for both
gcc and clang then this should be fine.
Christoph
> -- Keir
>
>> gcc -O2 -I/usr/include -I/usr/pkg/include -O2 -fomit-frame-pointer -m64
>> -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
>> -Wno-unused-value -Wdeclaration-after-statement -O2
>> -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall
>> -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -O2
>> -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall
>> -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
>> -DNDEBUG -nostdinc -fno-builtin -fno-common -Wredundant-decls
>> -iwithprefix include -Werror -Wno-pointer-arith -pipe
>> -I/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include
>> -I/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm-x86/
>> mach-generic
>> -I/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm-x86/
>> mach-default
>> -msoft-float -fno-stack-protector -fno-exceptions -mno-red-zone
>> -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE
>> -g -D__XEN__ -MMD -MF .xen.d -O2 -fomit-frame-pointer -m64
>> -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
>> -Wno-unused-value -Wdeclaration-after-statement -DNDEBUG -nostdinc
>> -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror
>> -Wno-pointer-arith -pipe
>> -I/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include
>> -I/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm-x86/
>> mach-generic
>> -I/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm-x86/
>> mach-default
>> -msoft-float -fno-stack-protector -fno-exceptions -mno-red-zone -fpic
>> -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -g
>> -D__XEN__ -MMD -MF .asm-offsets.s.d -S -o asm-offsets.s x86_64/asm-offsets.c
>> In file included from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/lib.h:
>> 5,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm/system
>> .h:4,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/spinlo
>> ck.h:5,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/sched.
>> h:7,
>> from x86_64/asm-offsets.c:10:
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/stdarg
>> .h:4:22:
>> error: stdarg.h: No such file or directory
>> In file included from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm/system
>> .h:4,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/spinlo
>> ck.h:5,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/sched.
>> h:7,
>> from x86_64/asm-offsets.c:10:
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/lib.h:
>> 86:
>> error: expected declaration specifiers or '...' before 'va_list'
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/lib.h:
>> 90:
>> error: expected declaration specifiers or '...' before 'va_list'
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/lib.h:
>> 94:
>> error: expected declaration specifiers or '...' before 'va_list'
>> In file included from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/acpi/acpi.
>> h:61,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/xen/acpi.h
>> :34,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/acpi/apei.
>> h:8,
>> from
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/asm/fixmap
>> .h:23,
>> from x86_64/asm-offsets.c:12:
>> /tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/include/acpi/acpio
>> sxf.h:257:
>> error: expected declaration specifiers or '...' before 'va_list'
>> gmake[3]: *** [asm-offsets.s] Error 1
>> gmake[3]: Leaving directory
>> `/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/arch/x86'
>> gmake[2]: ***
>> [/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen/xen] Error 2
>> gmake[2]: Leaving directory
>> `/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen'
>> gmake[1]: *** [install] Error 2
>> gmake[1]: Leaving directory
>> `/tmp/pkgsrc-obj/sysutils/xenkernel41/work.ixp/xen-4.1.0/xen'
>>
>>
>>>
>>> -- Keir
>>>
>>>>> Use the external header when we compile the tools.
>>>>> Adapt libelf-loader.c which is compiled in the kernel
>>>>> and with the tools.
>>>>
>>>> -#include<stdarg.h>
>>>> +#include "../../include/xen/stdarg.h"
>>>>
>>>> Firstly, is this correct for all uses of libelf-loader ? This file is
>>>> compiled both for use inside Xen and for use on the host. In the
>>>> latter case it /should/ use the system's stdarg.h.
>>>>
>>>> Also, this kind of relative path should not be necessary. The
>>>> relevant files should be on the include path.
>>>>
>>>> So I think this should be fixed by arranging that your new stdarg.h is
>>>> on the relevant include path, not by changing the .c file.
>>>>
>>>> Ian.
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next parent reply other threads:[~2011-05-27 9:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CA052B9C.2DB31%keir@xen.org>
2011-05-27 9:48 ` Christoph Egger [this message]
2011-05-27 13:13 ` [PATCH] xen: Deal with stdarg.h and -nostdinc Keir Fraser
2011-05-27 14:05 ` Christoph Egger
2011-05-27 14:41 ` Keir Fraser
2011-05-27 14:51 ` Keir Fraser
2011-05-27 15:08 ` Christoph Egger
2011-05-27 13:16 ` Tim Deegan
2011-05-27 13:19 ` Keir Fraser
2011-05-27 13:27 ` Tim Deegan
2011-05-27 13:30 ` Ian Campbell
2011-05-26 14:54 Christoph Egger
2011-05-26 15:00 ` Christoph Egger
2011-05-26 15:17 ` Keir Fraser
2011-05-26 15:19 ` Jan Beulich
2011-05-26 16:11 ` Ian Jackson
2011-05-26 17:08 ` Keir Fraser
2011-05-27 7:55 ` Christoph Egger
2011-05-27 8:46 ` Keir Fraser
2011-05-27 8:59 ` Christoph Egger
2011-05-27 10:57 ` Ian Jackson
2011-05-27 7:47 ` Christoph Egger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DDF735F.9020706@amd.com \
--to=christoph.egger@amd.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.