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

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 1 Mar 2021 10:07:42 +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=5huOBLLy9OiE8vIPLa7AJ5tUwdEztGNpNWZRhLiB8KA=; b=CYKgDrnysqKO09Ibtd4ekhjSL787kXaV/4M1oe4TqznQVptRbHmDFWGQW6XtWqWKsg3efyU+SFdHcJKPqwog0KkMfKMufxROOvhV7fnhaUOIqg0sVaNgYLdoIXuN91QkFR8PY474sAy+thbV2qeX9phyDFBaoDIkqbovP+S+uI7Ggo1kLhcOc9rWG0H7wg/0pBK1tU8mqp80uC+FBXzUIrzK+9b8RHsIQoyG8OxDoX19DD5Uy3as06oZqfrAP9AF2eGjBg4sQchsQYUcyzingNGJ6XOrzpz3iTQVcc1BN8di/vCVBN6f5tpPaRX5ByWYMgUKWvFBw1i5siUu6JqYyw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YV/SKS32bhDCJZQNxltk65WMV397fBMfk5D/HQJlX2+AnSpfmDVb2GuhrIm3I/4KBATvOeppHiaAHjghzZZ/IzdkVnrzV9eRjmISSL7Ys5oYi9UYb6hFvEjPaFUqOw7A6Ujdqmg7CbmuqgKu+CtRAuVj4hoZmfZPCc6NJ0an2XSSxJvnnQWp3durtRfyxR7ciCB3pTRLGuqjXZW0rn8Guiq2Lgdq/Oq2U6biYTZZxaz8gZhLBjKoIfQxY2Kh+5JOImeVfNdVmWT4uUtvUEyerJeMlbjs9UseSaB7Y84/87xKVp8A9SptYSSAtHRcwA0v8xyf24ttLb9psXunPcAtJA==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 01 Mar 2021 09:08:00 +0000
  • Ironport-sdr: CUTbo1FkNWhhsV4REikeTX72b65wm72oHsRW/5hwGSQQoSU517uM1KPEkIK0IxEIBfehc1M+ZG HUDBrYpbfawKQFWrNj295vIqu5WaOZBq6cRkVBYpmAiX5rTuaPeO5lrjGWL6j7bua4fwLTkTc8 SBau1zkBhYor7iCrKxz/TPqAaCkQL6Cdw4a/Nu75jTvwdj6lmlkqWBhE09TqfeHdawIvlUqO5X rsvdZSMTKb+wOFJkwEgbAWF/WvlveNP3LGufwo96RWKmhTUnu05No/MasYTY3/w0TwLILcdt/T nX0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Feb 26, 2021 at 02:24:43PM +0100, Jan Beulich wrote:
> On 26.02.2021 09:59, Roger Pau Monne wrote:
> > 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
> > path:
> > 
> > #include <...> search starts here:
> >  /usr/include
> >  /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include
> > 
> > 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
> > build.
> > 
> > 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>
> 
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> with possibly small adjustments:
> 
> > ---
> > 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:
> >  /usr/local/include
> >  /usr/lib/llvm-9/lib/clang/9.0.1/include
> >  /usr/include/x86_64-linux-gnu
> >  /usr/include
> > 
> > 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.
> 
> I agree (in particular given the observations), but I don't view
> this as an argument against use of -ffreestanding. In fact I'd
> rather see this change re-based on top of Andrew's changes. Then ...

But doesn't using -nostdinc kind of defeats the purpose of
-ffreestanding, as it would remove all default paths from the include
search, and thus prevent using the gcc private headers?

> > --- /dev/null
> > +++ b/tools/firmware/include/stdint.h
> > @@ -0,0 +1,39 @@
> > +#ifndef _STDINT_H_
> > +#define _STDINT_H_
> > +
> > +#ifdef __LP64__
> > +#error "32bit only header"
> > +#endif
> 
> Could I talk you into extending this to also cover __P64__? (The
> alternative I see would be to omit this altogether.)

Sure. I'm having a hard time finding any documentation for __P64__
however. Does it stand for pointers are 64 bits, while longs are
32bits?

Thanks, Roger.



 


Rackspace

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