[PATCH] arm64: add workaround for ambiguous C99 stdint.h types

[Ard Biesheuvel]

On 17 February 2014 18:42, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Mon, Feb 17, 2014 at 12:40:18PM +0000, Ard Biesheuvel wrote:
>> On 17 February 2014 13:23, Catalin Marinas <catalin.marinas at arm.com> wrote:
>> > On Sun, Jan 26, 2014 at 08:30:48PM +0000, Ard Biesheuvel wrote:
>> >> In a way similar to ARM commit 09096f6a0ee2 ("ARM: 7822/1: add workaround
>> >> for ambiguous C99 stdint.h types"), this patch redefines the macros that
>> >> are used in stdint.h so its definitions of uint64_t and int64_t are
>> >> compatible with those of the kernel.
>> >>
>> >> In order to do so, drop types.h from generic-y and create a specific arm64
>> >> version identical to the generic one with just the #define overrides added.
>> >
>> > I tried but still can't get what this patch is about. Do the
>> > linux/types.h types ever get to user space? We have uapi/linux/types.h
>> > for this.
>> >
>> > Can you give an example of where this is needed? Which source file
>> > includes both stdint.h and linux/types.h (non-uapi version)?
>>
>> It's not about user space, it is mainly about the use of NEON
>> instrinsics in the kernel.
>>
>> If you do the following:
>>
>> #Include <linux/types.h>
>> #include <arm_neon.h>
>
> For other intrinsics that we use like __builtin_ctzl(), do we need to
> explicitly include gcc headers? I don't think we do and I really don't
> like such arm_neon.h include which brings in other user headers. Don't
> we have any work around this?
>

Well, I talked to the toolchain guys at the time and they really
disliked the idea of coding directly against the __builtins because
they are not considered a stable interface, especially because the
interface that /is/ considered stable (arm_neon.h) is supported both
on ARM and on arm64.

> My inbox only has some discussion in May last year on the linaro-kernel
> list without any clear conclusion (it could be that I deleted other
> emails).
>

There was some discussion, indeed, but for ARM, with the conclusion
being the fix I mentioned in the patch: 09096f6a0ee2 ("ARM: 7822/1:
add workaround
for ambiguous C99 stdint.h types"), only in that case, the ambiguity
is (unsurprisingly) about the 32 bit types, not the 64 bit ones.

It all comes down to whether you are interested in supporting NEON
intrinsics (not __builtins, but intrinsics that require a support
header). If you do, this is probably the easiest way to do so, i.e.,
merge this patch and document the fact that the NEON intrinsics object
files need to be built with -ffreestanding (as is the case for ARM).
Only then can you freely #include <arm_neon.h> in code that also
(indirectly) includes <linux/types.h>.

Regards,
Ard.