From: Mark Rutland <mark.rutland@arm.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, Jaxson Han <jaxson.han@arm.com>
Subject: Re: [boot-wrapper PATCH v2 2/9] Add standard headers
Date: Tue, 11 Jan 2022 11:34:53 +0000 [thread overview]
Message-ID: <Yd1rXXvt3u2mSFf8@FVFF77S0Q05N> (raw)
In-Reply-To: <20220107143128.53eb87b2@donnerap.cambridge.arm.com>
On Fri, Jan 07, 2022 at 02:31:28PM +0000, Andre Przywara wrote:
> On Fri, 7 Jan 2022 13:49:43 +0000
> Mark Rutland <mark.rutland@arm.com> wrote:
>
> > On Wed, Dec 22, 2021 at 06:16:00PM +0000, Andre Przywara wrote:
> > > So far we were relying on some standard C headers to be provided by the
> > > toolchain. This applies for instance to stddef.h and stdint.h.
> > > As a "bare-metal" application, we should not rely on external headers,
> > > or even on a toolchain providing them in the first place.
> > >
> > > Define our own version of stddef.h and stdint.h, containing just the
> > > types that we actually need.
> >
> > Even a freestanding compiler implementation is required to provide these
> > headers, and using the compiler versions would avoid unexpected mismatches
> > (e.g. for builtins). So I don't think the justification as written makes sense.
> >
> > Is this because the next patch removes the stdinc paths, and so we don't get
> > the compiler's implementation of these headers?
>
> Yes, exactly. I don't like repeating those either, and understand that
> even a minimal compiler carries these headers, *somewhere*, but I couldn't
> find an easy way of including them without being compiler/build specific.
>
> I can try harder, and would be happy if someone points out the real
> solution to this.
>
> For the sake of solving this problem I figured that those particular
> definitions are actually somewhat generic (for all practical purposes), so
> it was the least involved solution to the real problem, which is to ditch
> the *other* compiler headers and libraries, as done in patch 3/9.
FWIW, if we do need to use -nostdinc to drop other headers, I'm happy to take
something like this, but I think that should be an atomic change -- we should
add -nostdinc and the headers at the same time, and be explicit in the commit
message as to the rationale.
I'm just torn as to whether we actually need -nostdinc, as IIUC we don't
strictly need to drop that for freestanding code, and IIRC we haven't had any
mistakes so far that stemmed from including headers that weren't suitable for
freestanding code.
So I'm tempted to say keep the standard includes for now.
Thanks,
Mark.
>
> Cheers,
> Andre
>
> > >
> > > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > > ---
> > > arch/aarch32/include/stdint.h | 19 +++++++++++++++++++
> > > arch/aarch64/include/stdint.h | 19 +++++++++++++++++++
> > > include/stddef.h | 15 +++++++++++++++
> > > 3 files changed, 53 insertions(+)
> > > create mode 100644 arch/aarch32/include/stdint.h
> > > create mode 100644 arch/aarch64/include/stdint.h
> > > create mode 100644 include/stddef.h
> > >
> > > diff --git a/arch/aarch32/include/stdint.h b/arch/aarch32/include/stdint.h
> > > new file mode 100644
> > > index 0000000..77546f0
> > > --- /dev/null
> > > +++ b/arch/aarch32/include/stdint.h
> > > @@ -0,0 +1,19 @@
> > > +/*
> > > + * arch/aarch32/include/stdint.h
> > > + *
> > > + * Copyright (C) 2021 ARM Limited. All rights reserved.
> > > + *
> > > + * Use of this source code is governed by a BSD-style license that can be
> > > + * found in the LICENSE.txt file.
> > > + */
> > > +#ifndef STDINT_H__
> > > +#define STDINT_H__
> > > +
> > > +typedef unsigned char uint8_t;
> > > +typedef unsigned short int uint16_t;
> > > +typedef unsigned int uint32_t;
> > > +typedef unsigned long long int uint64_t;
> > > +
> > > +typedef unsigned int uintptr_t;
> > > +
> > > +#endif
> > > diff --git a/arch/aarch64/include/stdint.h b/arch/aarch64/include/stdint.h
> > > new file mode 100644
> > > index 0000000..92c2603
> > > --- /dev/null
> > > +++ b/arch/aarch64/include/stdint.h
> > > @@ -0,0 +1,19 @@
> > > +/*
> > > + * arch/aarch64/include/stdint.h
> > > + *
> > > + * Copyright (C) 2021 ARM Limited. All rights reserved.
> > > + *
> > > + * Use of this source code is governed by a BSD-style license that can be
> > > + * found in the LICENSE.txt file.
> > > + */
> > > +#ifndef STDINT_H__
> > > +#define STDINT_H__
> > > +
> > > +typedef unsigned char uint8_t;
> > > +typedef unsigned short int uint16_t;
> > > +typedef unsigned int uint32_t;
> > > +typedef unsigned long int uint64_t;
> > > +
> > > +typedef unsigned long int uintptr_t;
> > > +
> > > +#endif
> > > diff --git a/include/stddef.h b/include/stddef.h
> > > new file mode 100644
> > > index 0000000..3208b10
> > > --- /dev/null
> > > +++ b/include/stddef.h
> > > @@ -0,0 +1,15 @@
> > > +/*
> > > + * include/stddef.h - standard data type definitions
> > > + *
> > > + * Copyright (C) 2021 ARM Limited. All rights reserved.
> > > + *
> > > + * Use of this source code is governed by a BSD-style license that can be
> > > + * found in the LICENSE.txt file.
> > > + */
> > > +#ifndef STDDEF_H__
> > > +#define STDDEF_H__
> > > +
> > > +typedef unsigned long int size_t;
> > > +typedef signed long int ssize_t;
> > > +
> > > +#endif
> > > --
> > > 2.25.1
> > >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-11 11:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-22 18:15 [boot-wrapper PATCH v2 0/9] Various (build system) fixes Andre Przywara
2021-12-22 18:15 ` [boot-wrapper PATCH v2 1/9] Makefile: Avoid .got section creation Andre Przywara
2022-01-07 13:49 ` Mark Rutland
2021-12-22 18:16 ` [boot-wrapper PATCH v2 2/9] Add standard headers Andre Przywara
2022-01-07 13:49 ` Mark Rutland
2022-01-07 14:31 ` Andre Przywara
2022-01-11 11:34 ` Mark Rutland [this message]
2021-12-22 18:16 ` [boot-wrapper PATCH v2 3/9] Makefile: Tell compiler to generate bare-metal code Andre Przywara
2022-01-07 13:53 ` Mark Rutland
2022-01-07 14:38 ` Andre Przywara
2022-01-11 11:30 ` Mark Rutland
2022-01-18 12:52 ` Andre Przywara
2022-01-18 14:10 ` Ard Biesheuvel
2021-12-22 18:16 ` [boot-wrapper PATCH v2 4/9] configure: Make PSCI the default boot method Andre Przywara
2022-01-07 14:12 ` Mark Rutland
2021-12-22 18:16 ` [boot-wrapper PATCH v2 5/9] configure: Fix default DTB Andre Przywara
2022-01-07 14:13 ` Mark Rutland
2021-12-22 18:16 ` [boot-wrapper PATCH v2 6/9] configure: Use earlycon instead of earlyprintk Andre Przywara
2022-01-07 14:01 ` Mark Rutland
2022-01-07 14:14 ` Mark Rutland
2022-01-07 14:47 ` Andre Przywara
2021-12-22 18:16 ` [boot-wrapper PATCH v2 7/9] pointer auth: Document CPU feature bit mask Andre Przywara
2022-01-07 14:15 ` Mark Rutland
2021-12-22 18:16 ` [boot-wrapper PATCH v2 8/9] configure: Autodetect GICv3 Andre Przywara
2022-01-07 14:19 ` Mark Rutland
2021-12-22 18:16 ` [boot-wrapper PATCH v2 9/9] avoid dtc warnings on re-compiling DTB Andre Przywara
2022-01-07 13:59 ` Mark Rutland
2022-01-13 18:42 ` Vladimir Murzin
2022-01-13 19:50 ` Andre Przywara
2022-01-14 8:35 ` Vladimir Murzin
2022-01-14 10:44 ` Mark Rutland
2022-01-14 12:09 ` Andre Przywara
2022-01-19 12:02 ` Mark Rutland
2022-01-07 14:25 ` [boot-wrapper PATCH v2 0/9] Various (build system) fixes Mark Rutland
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=Yd1rXXvt3u2mSFf8@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=andre.przywara@arm.com \
--cc=jaxson.han@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox