All of lore.kernel.org
 help / color / mirror / Atom feed
From: JackieLiu <liuyun01@kylinos.cn>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH v2 1/2] arm64: add workaround for ambiguous C99 stdint.h types
Date: Tue, 27 Nov 2018 18:01:40 +0800	[thread overview]
Message-ID: <36D96063-1722-4231-9810-CFAE6368616A@kylinos.cn> (raw)
In-Reply-To: <CAKv+Gu9TEZ9j3xB9dM_tP9tenzoH+p6Y7-1KCKGEL7AkiVdRdw@mail.gmail.com>

Yep, you are right. I will change code later.

But now, I found an new problem, when build the kernel, 
I got follow message:

WARNING: EXPORT symbol "xor_block_inner_neon" [arch/arm64/lib/xor-neon.ko] 
version generation failed, symbol will not be versioned.

I don’t know why, do you have any idea?

> 在 2018年11月27日,16:17,Ard Biesheuvel <ard.biesheuvel@linaro.org> 写道:
> 
> On Tue, 27 Nov 2018 at 06:28, Jackie Liu <liuyun01@kylinos.cn> 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.
>> 
>> This patch comes from: https://patchwork.kernel.org/patch/3540001/
>> Wrote by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> 
> 
> OK, I remember now :-)
> 
> So this is the reason you had two separate source files in the
> previous revision.
> 
> Could we maybe deal with this differently? Could we add a header
> 
> arch/arm64/include/asm/neon-intrinsics.h
> 
> that includes <arm_neon.h> after setting the preprocessor overrides
> below? And reference that header from your code?
> 
> That way, we don't have to override asm/types.h for everyone.
> 
> 
> 
>> Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
>> ---
>> arch/arm64/include/uapi/asm/types.h | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>> create mode 100644 arch/arm64/include/uapi/asm/types.h
>> 
>> diff --git a/arch/arm64/include/uapi/asm/types.h b/arch/arm64/include/uapi/asm/types.h
>> new file mode 100644
>> index 0000000..0016780
>> --- /dev/null
>> +++ b/arch/arm64/include/uapi/asm/types.h
>> @@ -0,0 +1,26 @@
>> +#ifndef _UAPI_ASM_TYPES_H
>> +#define _UAPI_ASM_TYPES_H
>> +
>> +#include <asm-generic/int-ll64.h>
>> +
>> +/*
>> + * For Aarch64, there is some ambiguity in the definition of the types below
>> + * between the kernel and GCC itself. This is usually not a big deal, but it
>> + * causes trouble when including GCC's version of 'stdint.h' (this is the file
>> + * that gets included when you #include <stdint.h> on a -ffreestanding build).
>> + * As this file also gets included implicitly when including 'arm_neon.h' (the
>> + * NEON intrinsics support header), we need the following to work around the
>> + * issue if we want to use NEON intrinsics in the kernel.
>> + */
>> +
>> +#ifdef __INT64_TYPE__
>> +#undef __INT64_TYPE__
>> +#define __INT64_TYPE__         __signed__ long long
>> +#endif
>> +
>> +#ifdef __UINT64_TYPE__
>> +#undef __UINT64_TYPE__
>> +#define __UINT64_TYPE__                unsigned long long
>> +#endif
>> +
>> +#endif /* _UAPI_ASM_TYPES_H */
>> --
>> 2.7.4
>> 
>> 
>> 
>> 
> 




WARNING: multiple messages have this Message-ID (diff)
From: liuyun01@kylinos.cn (JackieLiu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/2] arm64: add workaround for ambiguous C99 stdint.h types
Date: Tue, 27 Nov 2018 18:01:40 +0800	[thread overview]
Message-ID: <36D96063-1722-4231-9810-CFAE6368616A@kylinos.cn> (raw)
In-Reply-To: <CAKv+Gu9TEZ9j3xB9dM_tP9tenzoH+p6Y7-1KCKGEL7AkiVdRdw@mail.gmail.com>

Yep, you are right. I will change code later.

But now, I found an new problem, when build the kernel, 
I got follow message:

WARNING: EXPORT symbol "xor_block_inner_neon" [arch/arm64/lib/xor-neon.ko] 
version generation failed, symbol will not be versioned.

I don?t know why, do you have any idea?

> ? 2018?11?27??16:17?Ard Biesheuvel <ard.biesheuvel@linaro.org> ???
> 
> On Tue, 27 Nov 2018 at 06:28, Jackie Liu <liuyun01@kylinos.cn> 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.
>> 
>> This patch comes from: https://patchwork.kernel.org/patch/3540001/
>> Wrote by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> 
> 
> OK, I remember now :-)
> 
> So this is the reason you had two separate source files in the
> previous revision.
> 
> Could we maybe deal with this differently? Could we add a header
> 
> arch/arm64/include/asm/neon-intrinsics.h
> 
> that includes <arm_neon.h> after setting the preprocessor overrides
> below? And reference that header from your code?
> 
> That way, we don't have to override asm/types.h for everyone.
> 
> 
> 
>> Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
>> ---
>> arch/arm64/include/uapi/asm/types.h | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>> create mode 100644 arch/arm64/include/uapi/asm/types.h
>> 
>> diff --git a/arch/arm64/include/uapi/asm/types.h b/arch/arm64/include/uapi/asm/types.h
>> new file mode 100644
>> index 0000000..0016780
>> --- /dev/null
>> +++ b/arch/arm64/include/uapi/asm/types.h
>> @@ -0,0 +1,26 @@
>> +#ifndef _UAPI_ASM_TYPES_H
>> +#define _UAPI_ASM_TYPES_H
>> +
>> +#include <asm-generic/int-ll64.h>
>> +
>> +/*
>> + * For Aarch64, there is some ambiguity in the definition of the types below
>> + * between the kernel and GCC itself. This is usually not a big deal, but it
>> + * causes trouble when including GCC's version of 'stdint.h' (this is the file
>> + * that gets included when you #include <stdint.h> on a -ffreestanding build).
>> + * As this file also gets included implicitly when including 'arm_neon.h' (the
>> + * NEON intrinsics support header), we need the following to work around the
>> + * issue if we want to use NEON intrinsics in the kernel.
>> + */
>> +
>> +#ifdef __INT64_TYPE__
>> +#undef __INT64_TYPE__
>> +#define __INT64_TYPE__         __signed__ long long
>> +#endif
>> +
>> +#ifdef __UINT64_TYPE__
>> +#undef __UINT64_TYPE__
>> +#define __UINT64_TYPE__                unsigned long long
>> +#endif
>> +
>> +#endif /* _UAPI_ASM_TYPES_H */
>> --
>> 2.7.4
>> 
>> 
>> 
>> 
> 

  reply	other threads:[~2018-11-27 10:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27  5:27 [PATCH v2 1/2] arm64: add workaround for ambiguous C99 stdint.h types Jackie Liu
2018-11-27  5:27 ` Jackie Liu
2018-11-27  5:27 ` [PATCH v2 2/2] arm64: crypto: add NEON accelerated XOR implementation Jackie Liu
2018-11-27  5:27   ` Jackie Liu
2018-11-27  8:17 ` [PATCH v2 1/2] arm64: add workaround for ambiguous C99 stdint.h types Ard Biesheuvel
2018-11-27  8:17   ` Ard Biesheuvel
2018-11-27 10:01   ` JackieLiu [this message]
2018-11-27 10:01     ` JackieLiu

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=36D96063-1722-4231-9810-CFAE6368616A@kylinos.cn \
    --to=liuyun01@kylinos.cn \
    --cc=ard.biesheuvel@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.