[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH for-4.15 2/3] firmware: provide a stand alone set of headers

  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Date: Fri, 26 Feb 2021 09:59:07 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RV5OFa57bqpUoSqK0ZdahTgCjVx4yyQ9MfBf1+OuoDs=; b=n5RfmP/+q8YmfbZ1gSJlqSxcxEmBkNtEwRohmyz5+/fowAnbinkrDY7gLe5V3bLu3qRtrj4j35I2R4MDYhjZAE5rWIKXQjDPqhcdU54H66n++t/loZvboubmYczctyLShiA60jyVRhiiIX7ZuAs0KiCTDuChzMTvLqjj+JtIZSBZ74M7tY4pZWwSIxE2seSIKaDPTnhYxvPuvH/jHhKM7X4HrY/A9cYDZC4Ijzjve8WrZlN3qL//mH1A7ytO1yo/SY28C1TUWlS4kEnGcfoHCJTAnVgwv7bptii+i7gep5GUcB1HoV+qWv137bVHq1k3ResferWt4NH98uDqLtcjCA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vlsow9uwpk4IXlP3nriwoSvcbEqRh5tEUOyUkRRwahuuMVJNyzT//PXm6LQtyBPkfi4OJQadgsA5YYBzxgsJlwXaT8alWIPthvMhYNJHk/7QKogK77XmFLnuP9b3LxDmXpPxt+p4d1YCfE/4GYGzUlzm9Bo1no7vK7yZk6anWZAFUzTSvrnsalwTG2K4ZnDc7N9qK3ReW8qIdU/pzzTWk0yh721tWZWRGSOYgDE0BmQGJD9LrkX6jujMrTYnJSkUKuRB8/0w7WqhU1y0E1EOBeitBv1f23DaOUbSURJYnIQWxW8h2ol5LHjvhG9/ZeWnBTHs5cvKdJM7NsgS5CkmoQ==
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "Ian Jackson" <iwj@xxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Fri, 26 Feb 2021 09:00:54 +0000
  • Ironport-sdr: jLi68Waa/N8LQ0PKHVnvgKUNu9Nu5VuifzXXhWDLOMrHKF/0yz7PG6Kr4AoX3uODmuluIY5YL8 jFwU6LF5wGJ2Vb2MEiYNYnZZBzfH0MJmxHimH7fY25j0TL0WIs2sWJCdkgfupN7cIstcO2F/CM 1bPFeF4bKMqBwctLN6bWLjtjwJhIqcOz06TN/o2kXMqD7YgSbhHZP424VeAI8YF3+JAM9Xy1Ad PQWQIvnBfdIp5lkhwXatTSfISSCnotd0PW+jmLpXflpOz7JMdq9HscSB2UUMVXq913zLh2kW6+ 0T0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

The current build of the firmware relies on having 32bit compatible
headers installed in order to build some of the 32bit firmware, but
that usually requires multilib support and installing a i386 libc when
building from an amd64 environment which is cumbersome just to get
some headers.

Usually this could be solved by using the -ffreestanding compiler
option which drops the usage of the system headers in favor of a
private set of freestanding headers provided by the compiler itself
that are not tied to libc. However such option is broken at least
in the gcc compiler provided in Alpine Linux, as the system include
path (ie: /usr/include) takes precedence over the gcc private include

#include <...> search starts here:

Since -ffreestanding is currently broken on at least that distro, and
for resilience against future compilers also having the option broken
provide a set of stand alone 32bit headers required for the firmware

This allows to drop the build time dependency on having a i386
compatible set of libc headers on amd64.

Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
There's the argument of fixing gcc in Alpine and instead just use
-ffreestanding. I think that's more fragile than providing our own set
of stand alone headers for the firmware bits. Having the include paths
wrongly sorted can easily make the system headers being picked up
instead of the gcc ones, and then building can randomly fail because
the system headers could be amd64 only (like the musl ones).

I've also seen clang-9 on Debian with the following include paths:

#include "..." search starts here:
#include <...> search starts here:

Which also seems slightly dangerous as local comes before the compiler
private path.

IMO using our own set of stand alone headers is more resilient.

Regarding the release risks, the main one would be breaking the build
(as it's currently broken on Alpine). I think there's a very low risk
of this change successfully producing a binary image that's broken,
and hence with enough build testing it should be safe to merge.
 README                                        |  3 --
 tools/firmware/Rules.mk                       | 11 ++++++
 tools/firmware/include/stdarg.h               | 10 +++++
 tools/firmware/include/stdbool.h              |  9 +++++
 tools/firmware/include/stddef.h               | 10 +++++
 tools/firmware/include/stdint.h               | 39 +++++++++++++++++++
 tools/firmware/rombios/32bit/rombios_compat.h |  4 +-
 7 files changed, 80 insertions(+), 6 deletions(-)
 create mode 100644 tools/firmware/include/stdarg.h
 create mode 100644 tools/firmware/include/stdbool.h
 create mode 100644 tools/firmware/include/stddef.h
 create mode 100644 tools/firmware/include/stdint.h

diff --git a/README b/README
index 33cdf6b826..5167bb1708 100644
--- a/README
+++ b/README
@@ -62,9 +62,6 @@ provided by your OS distributor:
     * GNU bison and GNU flex
     * GNU gettext
     * ACPI ASL compiler (iasl)
-    * Libc multiarch package (e.g. libc6-dev-i386 / glibc-devel.i686).
-      Required when building on a 64-bit platform to build
-      32-bit components which are enabled on a default build.
 In addition to the above there are a number of optional build
 prerequisites. Omitting these will cause the related features to be
diff --git a/tools/firmware/Rules.mk b/tools/firmware/Rules.mk
index 26bbddccd4..5d09ab06df 100644
--- a/tools/firmware/Rules.mk
+++ b/tools/firmware/Rules.mk
@@ -17,3 +17,14 @@ $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 # Extra CFLAGS suitable for an embedded type of environment.
 CFLAGS += -fno-builtin -msoft-float
+# Use our own set of library headers to build firmware.
+# Ideally we would instead use -ffreestanding, but that relies on the compiler
+# having the right order for include paths (ie: compiler private headers before
+# system ones). This is not the case in Alpine at least which searches system
+# headers before compiler ones, and has been reported upstream:
+# https://gitlab.alpinelinux.org/alpine/aports/-/issues/12477
+# In the meantime (and for resilience against broken compilers) use our own set
+# of headers that provide what's needed for the firmware build.
+CFLAGS += -nostdinc -I$(XEN_ROOT)/tools/firmware/include
diff --git a/tools/firmware/include/stdarg.h b/tools/firmware/include/stdarg.h
new file mode 100644
index 0000000000..c5e3761cd2
--- /dev/null
+++ b/tools/firmware/include/stdarg.h
@@ -0,0 +1,10 @@
+#ifndef _STDARG_H_
+#define _STDARG_H_
+typedef __builtin_va_list va_list;
+#define va_copy(dest, src) __builtin_va_copy(dest, src)
+#define va_start(ap, last) __builtin_va_start(ap, last)
+#define va_end(ap) __builtin_va_end(ap)
+#define va_arg __builtin_va_arg
diff --git a/tools/firmware/include/stdbool.h b/tools/firmware/include/stdbool.h
new file mode 100644
index 0000000000..0cf76b106c
--- /dev/null
+++ b/tools/firmware/include/stdbool.h
@@ -0,0 +1,9 @@
+#ifndef _STDBOOL_H_
+#define _STDBOOL_H_
+#define bool _Bool
+#define true 1
+#define false 0
+#define __bool_true_false_are_defined 1
diff --git a/tools/firmware/include/stddef.h b/tools/firmware/include/stddef.h
new file mode 100644
index 0000000000..c7f974608a
--- /dev/null
+++ b/tools/firmware/include/stddef.h
@@ -0,0 +1,10 @@
+#ifndef _STDDEF_H_
+#define _STDDEF_H_
+typedef __SIZE_TYPE__ size_t;
+#define NULL ((void*)0)
+#define offsetof(t, m) __builtin_offsetof(t, m)
diff --git a/tools/firmware/include/stdint.h b/tools/firmware/include/stdint.h
new file mode 100644
index 0000000000..7514096846
--- /dev/null
+++ b/tools/firmware/include/stdint.h
@@ -0,0 +1,39 @@
+#ifndef _STDINT_H_
+#define _STDINT_H_
+#ifdef __LP64__
+#error "32bit only header"
+typedef unsigned char uint8_t;
+typedef signed char int8_t;
+typedef unsigned short uint16_t;
+typedef signed short int16_t;
+typedef unsigned int uint32_t;
+typedef signed int int32_t;
+typedef unsigned long long uint64_t;
+typedef signed long long int64_t;
+#define INT8_MIN        (-0x7f-1)
+#define INT16_MIN       (-0x7fff-1)
+#define INT32_MIN       (-0x7fffffff-1)
+#define INT64_MIN       (-0x7fffffffffffffffll-1)
+#define INT8_MAX        0x7f
+#define INT16_MAX       0x7fff
+#define INT32_MAX       0x7fffffff
+#define INT64_MAX       0x7fffffffffffffffll
+#define UINT8_MAX       0xff
+#define UINT16_MAX      0xffff
+#define UINT32_MAX      0xffffffffu
+#define UINT64_MAX      0xffffffffffffffffull
+typedef uint32_t uintptr_t;
+#define UINTPTR_MAX     UINT32_MAX
diff --git a/tools/firmware/rombios/32bit/rombios_compat.h 
index 3fe7d67721..8ba4c17ffd 100644
--- a/tools/firmware/rombios/32bit/rombios_compat.h
+++ b/tools/firmware/rombios/32bit/rombios_compat.h
@@ -8,9 +8,7 @@
 #define ADDR_FROM_SEG_OFF(seg, off)  (void *)((((uint32_t)(seg)) << 4) + (off))
-typedef unsigned char uint8_t;
-typedef unsigned short int uint16_t;
-typedef unsigned int uint32_t;
+#include <stdint.h>
 typedef uint8_t  Bit8u;
 typedef uint16_t Bit16u;



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.