From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: [PATCH] xen: Deal with stdarg.h and -nostdinc Date: Fri, 27 May 2011 11:48:15 +0200 Message-ID: <4DDF735F.9020706@amd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "xen-devel@lists.xensource.com" , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 05/27/11 11:21, Keir Fraser wrote: > On 27/05/2011 08:55, "Christoph Egger" 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 and are not found. That way 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 >>>> +#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