* [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
@ 2013-08-09 7:36 Ard Biesheuvel
2013-08-09 14:14 ` Dave Martin
2013-08-13 18:33 ` Ard Biesheuvel
0 siblings, 2 replies; 6+ messages in thread
From: Ard Biesheuvel @ 2013-08-09 7:36 UTC (permalink / raw)
To: linux-arm-kernel
The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
unambiguous on ARM as you would expect. For the types below, there is a
difference on ARM between GCC built for bare metal ARM, GCC built for glibc
and the kernel itself, which results in build errors if you try to build with
-ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
in order to use NEON intrinsics)
As the typedefs for these types in 'stdint.h' are based on builtin defines
supplied by GCC, we can tweak these to align with the kernel's idea of those
types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
source file (provided that -ffreestanding is used).
int32_t uint32_t uintptr_t
bare metal GCC long unsigned long unsigned long
glibc GCC int unsigned int unsigned int
kernel int unsigned int unsigned long
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
Hi all,
This is another, less obtrusive way of handling the problem for which I
previously sent an RFC patch 'types.h: use GCC supplied typedefs if appropriate'
In this case, only source files that in fact include stdint.h and are being
built for ARM should be affected.
Regards,
--
Ard.
arch/arm/include/asm/types.h | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 arch/arm/include/asm/types.h
diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
new file mode 100644
index 0000000..976ac31
--- /dev/null
+++ b/arch/arm/include/asm/types.h
@@ -0,0 +1,40 @@
+#ifndef _ASM_TYPES_H
+#define _ASM_TYPES_H
+
+#include <asm-generic/int-ll64.h>
+
+/*
+ * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
+ * unambiguous on ARM as you would expect. For the types below, there is a
+ * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
+ * and the kernel itself, which results in build errors if you try to build with
+ * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
+ * in order to use NEON intrinsics)
+ *
+ * As the typedefs for these types in 'stdint.h' are based on builtin defines
+ * supplied by GCC, we can tweak these to align with the kernel's idea of those
+ * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
+ * source file (provided that -ffreestanding is used).
+ *
+ * int32_t uint32_t uintptr_t
+ * bare metal GCC long unsigned long unsigned long
+ * glibc GCC int unsigned int unsigned int
+ * kernel int unsigned int unsigned long
+ */
+
+#ifdef __INT32__TYPE__
+#undef __INT32__TYPE__
+#define __INT32__TYPE__ int
+#endif
+
+#ifdef __UINT32__TYPE__
+#undef __UINT32__TYPE__
+#define __UINT32__TYPE__ unsigned int
+#endif
+
+#ifdef __UINTPTR_TYPE__
+#undef __UINTPTR_TYPE__
+#define __UINTPTR_TYPE__ unsigned long
+#endif
+
+#endif /* _ASM_TYPES_H */
--
1.8.1.2
^ permalink raw reply related [flat|nested] 6+ messages in thread* [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
2013-08-09 7:36 [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types Ard Biesheuvel
@ 2013-08-09 14:14 ` Dave Martin
2013-08-09 14:18 ` Ard Biesheuvel
2013-08-13 18:33 ` Ard Biesheuvel
1 sibling, 1 reply; 6+ messages in thread
From: Dave Martin @ 2013-08-09 14:14 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 09, 2013 at 09:36:42AM +0200, Ard Biesheuvel wrote:
> The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> unambiguous on ARM as you would expect. For the types below, there is a
> difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> and the kernel itself, which results in build errors if you try to build with
> -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> in order to use NEON intrinsics)
>
> As the typedefs for these types in 'stdint.h' are based on builtin defines
> supplied by GCC, we can tweak these to align with the kernel's idea of those
> types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> source file (provided that -ffreestanding is used).
>
> int32_t uint32_t uintptr_t
> bare metal GCC long unsigned long unsigned long
> glibc GCC int unsigned int unsigned int
> kernel int unsigned int unsigned long
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Hi all,
>
> This is another, less obtrusive way of handling the problem for which I
> previously sent an RFC patch 'types.h: use GCC supplied typedefs if appropriate'
> In this case, only source files that in fact include stdint.h and are being
> built for ARM should be affected.
>
> Regards,
> --
> Ard.
>
>
> arch/arm/include/asm/types.h | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 arch/arm/include/asm/types.h
>
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> new file mode 100644
> index 0000000..976ac31
> --- /dev/null
> +++ b/arch/arm/include/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _ASM_TYPES_H
> +#define _ASM_TYPES_H
> +
> +#include <asm-generic/int-ll64.h>
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> + * and the kernel itself, which results in build errors if you try to build with
> + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> + * source file (provided that -ffreestanding is used).
> + *
> + * int32_t uint32_t uintptr_t
> + * bare metal GCC long unsigned long unsigned long
> + * glibc GCC int unsigned int unsigned int
> + * kernel int unsigned int unsigned long
> + */
> +
> +#ifdef __INT32__TYPE__
> +#undef __INT32__TYPE__
> +#define __INT32__TYPE__ int
> +#endif
> +
> +#ifdef __UINT32__TYPE__
> +#undef __UINT32__TYPE__
> +#define __UINT32__TYPE__ unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
Somebody else might have the opposite problem to ARM, so I'm doubtful
about whether it's safe to do this for all arches. The arch maintainers
would have to comment on that. This looks ugly in an otherwise generic
header.
(As a cosmetic thing, you can lose the #ifdefs. #undef doesn't trigger
an error of the specified macro doesn't already exist.)
Cheers
---Dave
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
2013-08-09 14:14 ` Dave Martin
@ 2013-08-09 14:18 ` Ard Biesheuvel
2013-08-09 14:30 ` Dave Martin
0 siblings, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2013-08-09 14:18 UTC (permalink / raw)
To: linux-arm-kernel
On 9 August 2013 16:14, Dave Martin <Dave.Martin@arm.com> wrote:
> On Fri, Aug 09, 2013 at 09:36:42AM +0200, Ard Biesheuvel wrote:
[...]
> Somebody else might have the opposite problem to ARM, so I'm doubtful
> about whether it's safe to do this for all arches. The arch maintainers
> would have to comment on that. This looks ugly in an otherwise generic
> header.
>
This is actually under arch/arm so that should not be a problem. In
fact, it's a copy of asm-generic/types.h with just the #defines added.
> (As a cosmetic thing, you can lose the #ifdefs. #undef doesn't trigger
> an error of the specified macro doesn't already exist.)
>
I am aware of that, but I think it is cleaner not to pollute the
namespace if the defines weren't there to begin with.
Cheers,
Ard.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
2013-08-09 14:18 ` Ard Biesheuvel
@ 2013-08-09 14:30 ` Dave Martin
0 siblings, 0 replies; 6+ messages in thread
From: Dave Martin @ 2013-08-09 14:30 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Aug 09, 2013 at 04:18:30PM +0200, Ard Biesheuvel wrote:
> On 9 August 2013 16:14, Dave Martin <Dave.Martin@arm.com> wrote:
> > On Fri, Aug 09, 2013 at 09:36:42AM +0200, Ard Biesheuvel wrote:
>
> [...]
>
> > Somebody else might have the opposite problem to ARM, so I'm doubtful
> > about whether it's safe to do this for all arches. The arch maintainers
> > would have to comment on that. This looks ugly in an otherwise generic
> > header.
> >
>
> This is actually under arch/arm so that should not be a problem. In
> fact, it's a copy of asm-generic/types.h with just the #defines added.
Duh. Misread your patch, sorry about that.
> > (As a cosmetic thing, you can lose the #ifdefs. #undef doesn't trigger
> > an error of the specified macro doesn't already exist.)
> >
>
> I am aware of that, but I think it is cleaner not to pollute the
> namespace if the defines weren't there to begin with.
Ah, I see what you mean. Yes, that makes sense. I'd read the #ifdefs
as just being there to avoid redefinition errors.
I'll leave the thread for other people to comment, but this looks like
a reasonable thing to do for now.
Because the kernel is not a hosted C environment, we shouldn't be including
any foreign headers which care about the distinction, except for GCC's own
headers like arm_neon.h.
Cheers
---Dave
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
2013-08-09 7:36 [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types Ard Biesheuvel
2013-08-09 14:14 ` Dave Martin
@ 2013-08-13 18:33 ` Ard Biesheuvel
2013-08-13 23:33 ` Nicolas Pitre
1 sibling, 1 reply; 6+ messages in thread
From: Ard Biesheuvel @ 2013-08-13 18:33 UTC (permalink / raw)
To: linux-arm-kernel
Kinda-acked-by Dave Martin, anyone else care to comment?
On 9 August 2013 09:36, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> unambiguous on ARM as you would expect. For the types below, there is a
> difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> and the kernel itself, which results in build errors if you try to build with
> -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> in order to use NEON intrinsics)
>
> As the typedefs for these types in 'stdint.h' are based on builtin defines
> supplied by GCC, we can tweak these to align with the kernel's idea of those
> types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> source file (provided that -ffreestanding is used).
>
> int32_t uint32_t uintptr_t
> bare metal GCC long unsigned long unsigned long
> glibc GCC int unsigned int unsigned int
> kernel int unsigned int unsigned long
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>
> Hi all,
>
> This is another, less obtrusive way of handling the problem for which I
> previously sent an RFC patch 'types.h: use GCC supplied typedefs if appropriate'
> In this case, only source files that in fact include stdint.h and are being
> built for ARM should be affected.
>
> Regards,
> --
> Ard.
>
>
> arch/arm/include/asm/types.h | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 arch/arm/include/asm/types.h
>
> diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> new file mode 100644
> index 0000000..976ac31
> --- /dev/null
> +++ b/arch/arm/include/asm/types.h
> @@ -0,0 +1,40 @@
> +#ifndef _ASM_TYPES_H
> +#define _ASM_TYPES_H
> +
> +#include <asm-generic/int-ll64.h>
> +
> +/*
> + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> + * unambiguous on ARM as you would expect. For the types below, there is a
> + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> + * and the kernel itself, which results in build errors if you try to build with
> + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> + * in order to use NEON intrinsics)
> + *
> + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> + * supplied by GCC, we can tweak these to align with the kernel's idea of those
> + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> + * source file (provided that -ffreestanding is used).
> + *
> + * int32_t uint32_t uintptr_t
> + * bare metal GCC long unsigned long unsigned long
> + * glibc GCC int unsigned int unsigned int
> + * kernel int unsigned int unsigned long
> + */
> +
> +#ifdef __INT32__TYPE__
> +#undef __INT32__TYPE__
> +#define __INT32__TYPE__ int
> +#endif
> +
> +#ifdef __UINT32__TYPE__
> +#undef __UINT32__TYPE__
> +#define __UINT32__TYPE__ unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__ unsigned long
> +#endif
> +
> +#endif /* _ASM_TYPES_H */
> --
> 1.8.1.2
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types
2013-08-13 18:33 ` Ard Biesheuvel
@ 2013-08-13 23:33 ` Nicolas Pitre
0 siblings, 0 replies; 6+ messages in thread
From: Nicolas Pitre @ 2013-08-13 23:33 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 13 Aug 2013, Ard Biesheuvel wrote:
> Kinda-acked-by Dave Martin, anyone else care to comment?
>
Acked-by: Nicolas Pitre <nico@linaro.org>
> On 9 August 2013 09:36, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> > unambiguous on ARM as you would expect. For the types below, there is a
> > difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> > and the kernel itself, which results in build errors if you try to build with
> > -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> > in order to use NEON intrinsics)
> >
> > As the typedefs for these types in 'stdint.h' are based on builtin defines
> > supplied by GCC, we can tweak these to align with the kernel's idea of those
> > types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> > source file (provided that -ffreestanding is used).
> >
> > int32_t uint32_t uintptr_t
> > bare metal GCC long unsigned long unsigned long
> > glibc GCC int unsigned int unsigned int
> > kernel int unsigned int unsigned long
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> >
> > Hi all,
> >
> > This is another, less obtrusive way of handling the problem for which I
> > previously sent an RFC patch 'types.h: use GCC supplied typedefs if appropriate'
> > In this case, only source files that in fact include stdint.h and are being
> > built for ARM should be affected.
> >
> > Regards,
> > --
> > Ard.
> >
> >
> > arch/arm/include/asm/types.h | 40 ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 40 insertions(+)
> > create mode 100644 arch/arm/include/asm/types.h
> >
> > diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
> > new file mode 100644
> > index 0000000..976ac31
> > --- /dev/null
> > +++ b/arch/arm/include/asm/types.h
> > @@ -0,0 +1,40 @@
> > +#ifndef _ASM_TYPES_H
> > +#define _ASM_TYPES_H
> > +
> > +#include <asm-generic/int-ll64.h>
> > +
> > +/*
> > + * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
> > + * unambiguous on ARM as you would expect. For the types below, there is a
> > + * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
> > + * and the kernel itself, which results in build errors if you try to build with
> > + * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
> > + * in order to use NEON intrinsics)
> > + *
> > + * As the typedefs for these types in 'stdint.h' are based on builtin defines
> > + * supplied by GCC, we can tweak these to align with the kernel's idea of those
> > + * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
> > + * source file (provided that -ffreestanding is used).
> > + *
> > + * int32_t uint32_t uintptr_t
> > + * bare metal GCC long unsigned long unsigned long
> > + * glibc GCC int unsigned int unsigned int
> > + * kernel int unsigned int unsigned long
> > + */
> > +
> > +#ifdef __INT32__TYPE__
> > +#undef __INT32__TYPE__
> > +#define __INT32__TYPE__ int
> > +#endif
> > +
> > +#ifdef __UINT32__TYPE__
> > +#undef __UINT32__TYPE__
> > +#define __UINT32__TYPE__ unsigned int
> > +#endif
> > +
> > +#ifdef __UINTPTR_TYPE__
> > +#undef __UINTPTR_TYPE__
> > +#define __UINTPTR_TYPE__ unsigned long
> > +#endif
> > +
> > +#endif /* _ASM_TYPES_H */
> > --
> > 1.8.1.2
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-08-13 23:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-09 7:36 [RFC PATCH] ARM: add workaround for ambiguous C99 stdint.h types Ard Biesheuvel
2013-08-09 14:14 ` Dave Martin
2013-08-09 14:18 ` Ard Biesheuvel
2013-08-09 14:30 ` Dave Martin
2013-08-13 18:33 ` Ard Biesheuvel
2013-08-13 23:33 ` Nicolas Pitre
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).