[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 0/2] hvmloader: drop usage of system headers
On Wed, Feb 24, 2021 at 08:08:25PM +0000, Andrew Cooper wrote: > On 24/02/2021 10:26, Roger Pau Monne wrote: > > Hello, > > > > Following two patches aim to make hvmloader standalone, so that it don't > > try to use system headers. It shouldn't result in any functional > > change. > > > > Thanks, Roger. > > After some experimentation in the arch container I'm afraid it's the alpine container the one that gives those errors, not the arch one. So I've done some testing on alpine and I think there's something broken. Given the following snipped: --- #include <stdint.h> int main(void) { _Static_assert(sizeof(uint64_t) == 8, ""); } --- This is the output of running `gcc -E -m32 -ffreestanding test.c` on an alpine chroot that has just the 'gcc' package installed: --- # 1 "test.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "test.c" # 1 "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/stdint.h" 1 3 # 11 "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/stdint.h" 3 # 1 "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/stdint-gcc.h" 1 3 # 34 "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/stdint-gcc.h" 3 # 34 "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/stdint-gcc.h" 3 typedef signed char int8_t; typedef short int int16_t; typedef int int32_t; typedef long long int int64_t; typedef unsigned char uint8_t; typedef short unsigned int uint16_t; typedef unsigned int uint32_t; typedef long long unsigned int uint64_t; typedef signed char int_least8_t; typedef short int int_least16_t; typedef int int_least32_t; typedef long long int int_least64_t; typedef unsigned char uint_least8_t; typedef short unsigned int uint_least16_t; typedef unsigned int uint_least32_t; typedef long long unsigned int uint_least64_t; typedef signed char int_fast8_t; typedef int int_fast16_t; typedef int int_fast32_t; typedef long long int int_fast64_t; typedef unsigned char uint_fast8_t; typedef unsigned int uint_fast16_t; typedef unsigned int uint_fast32_t; typedef long long unsigned int uint_fast64_t; typedef int intptr_t; typedef unsigned int uintptr_t; typedef long long int intmax_t; typedef long long unsigned int uintmax_t; # 12 "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/stdint.h" 2 3 # 3 "test.c" 2 # 4 "test.c" int main(void) { _Static_assert(sizeof(uint64_t) == 8, ""); } --- OTOH, this is the output of the same command run on a chroot that has the full list of packages required to build Xen (from automation/build/alpine/3.12.dockerfile): --- # 1 "test.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "test.c" # 1 "/usr/include/stdint.h" 1 3 4 # 20 "/usr/include/stdint.h" 3 4 # 1 "/usr/include/bits/alltypes.h" 1 3 4 # 55 "/usr/include/bits/alltypes.h" 3 4 # 55 "/usr/include/bits/alltypes.h" 3 4 typedef unsigned long uintptr_t; # 70 "/usr/include/bits/alltypes.h" 3 4 typedef long intptr_t; # 96 "/usr/include/bits/alltypes.h" 3 4 typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed long int64_t; typedef signed long intmax_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned long uint64_t; # 146 "/usr/include/bits/alltypes.h" 3 4 typedef unsigned long uintmax_t; # 21 "/usr/include/stdint.h" 2 3 4 typedef int8_t int_fast8_t; typedef int64_t int_fast64_t; typedef int8_t int_least8_t; typedef int16_t int_least16_t; typedef int32_t int_least32_t; typedef int64_t int_least64_t; typedef uint8_t uint_fast8_t; typedef uint64_t uint_fast64_t; typedef uint8_t uint_least8_t; typedef uint16_t uint_least16_t; typedef uint32_t uint_least32_t; typedef uint64_t uint_least64_t; # 95 "/usr/include/stdint.h" 3 4 # 1 "/usr/include/bits/stdint.h" 1 3 4 typedef int32_t int_fast16_t; typedef int32_t int_fast32_t; typedef uint32_t uint_fast16_t; typedef uint32_t uint_fast32_t; # 96 "/usr/include/stdint.h" 2 3 4 # 3 "test.c" 2 # 4 "test.c" int main(void) { _Static_assert(sizeof(uint64_t) == 8, ""); } --- This is caused by the include path order of gcc on alpine, ie: --- # cpp -v /dev/null -o /dev/null Using built-in specs. COLLECT_GCC=cpp Target: x86_64-alpine-linux-musl Configured with: /home/buildozer/aports/main/gcc/src/gcc-10.2.1_pre1/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl --target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 10.2.1_pre1' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,d,objc,go,fortran,ada --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.1 20201203 (Alpine 10.2.1_pre1) COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-alpine-linux-musl/10.2.1/cc1 -E -quiet -v /dev/null -o /dev/null -mtune=generic -march=x86-64 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/include" ignoring nonexistent directory "/usr/include/fortify" #include "..." search starts here: #include <...> search starts here: /usr/include /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include End of search list. COMPILER_PATH=/usr/libexec/gcc/x86_64-alpine-linux-musl/10.2.1/:/usr/libexec/gcc/x86_64-alpine-linux-musl/10.2.1/:/usr/libexec/gcc/x86_64-alpine-linux-musl/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/:/usr/lib/gcc/x86_64-alpine-linux-musl/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/bin/ LIBRARY_PATH=/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/lib/../lib/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../../x86_64-alpine-linux-musl/lib/:/usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64' --- /usr/include takes precedence over the gcc private headers, and thus the usage of the -ffreestanding option is broken. On my Debian system this is: --- # cpp -v /dev/null -o /dev/null Using built-in specs. COLLECT_GCC=cpp Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/6/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu /dev/null -o /dev/null -mtune=generic -march=x86-64 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/6/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/6/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/6/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/6/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-E' '-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64' --- Which seems fine as the gcc private include path takes precedence over /usr/{,local/}include. Will try to figure out if there's a way to fix or workaround this brokenness. Roger.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |