Re: [PATCH kernel v2] powerpc/makefile: Do not redefine $(CPP) for preprocessor

0 views
Skip to first unread message

Segher Boessenkool

unread,
May 11, 2021, 7:23:37 AM5/11/21
to Alexey Kardashevskiy, linuxp...@lists.ozlabs.org, Michal Marek, linux-...@vger.kernel.org, Masahiro Yamada, Nick Desaulniers, linux-...@vger.kernel.org, Nathan Chancellor, clang-bu...@googlegroups.com, Nicholas Piggin
Hi!

On Tue, May 11, 2021 at 02:48:12PM +1000, Alexey Kardashevskiy wrote:
> --- a/arch/powerpc/kernel/vdso32/Makefile
> +++ b/arch/powerpc/kernel/vdso32/Makefile
> @@ -44,7 +44,7 @@ asflags-y := -D__VDSO32__ -s
>
> obj-y += vdso32_wrapper.o
> targets += vdso32.lds
> -CPPFLAGS_vdso32.lds += -P -C -Upowerpc
> +CPPFLAGS_vdso32.lds += -C
>
> # link rule for the .so file, .lds has to be first
> $(obj)/vdso32.so.dbg: $(src)/vdso32.lds $(obj-vdso32) $(obj)/vgettimeofday.o FORCE

> --- a/arch/powerpc/kernel/vdso64/Makefile
> +++ b/arch/powerpc/kernel/vdso64/Makefile
> @@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
> asflags-y := -D__VDSO64__ -s
>
> targets += vdso64.lds
> -CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
> +CPPFLAGS_vdso64.lds += -C
>
> # link rule for the .so file, .lds has to be first
> $(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE

Why are you removing -P and -Upowerpc here? "powerpc" is a predefined
macro on powerpc-linux (no underscores or anything, just the bareword).
This is historical, like "unix" and "linux". If you use the C
preprocessor for things that are not C code (like the kernel does here)
you need to undefine these macros, if anything in the files you run
through the preprocessor contains those words, or funny / strange / bad
things will happen. Presumably at some time in the past it did contain
"powerpc" somewhere.

-P is to inhibit line number output. Whatever consumes the
preprocessor output will have to handle line directives if you remove
this flag. Did you check if this will work for everything that uses
$(CPP)?

In any case, please mention the reasoning (and the fact that you are
removing these flags!) in the commit message. Thanks!


Segher

Alexey Kardashevskiy

unread,
May 11, 2021, 9:30:25 AM5/11/21
to Segher Boessenkool, Michal Marek, linux-...@vger.kernel.org, Masahiro Yamada, Nick Desaulniers, linux-...@vger.kernel.org, Nicholas Piggin, Nathan Chancellor, clang-bu...@googlegroups.com, linuxp...@lists.ozlabs.org
i don't know about everything for sure but i checked few configs and in all cases (except vdso) $CPP was receiving cflags.


In any case, please mention the reasoning (and the fact that you are
removing these flags!) in the commit message.  Thanks!


but i did mention this, the last paragraph... they are duplicated.



Segher

Alexey Kardashevskiy

unread,
May 11, 2021, 1:44:22 PM5/11/21
to linuxp...@lists.ozlabs.org, Alexey Kardashevskiy, Christophe Leroy, Masahiro Yamada, Michael Ellerman, Michal Marek, Nathan Chancellor, Nicholas Piggin, Nick Desaulniers, clang-bu...@googlegroups.com, linux-...@vger.kernel.org, linux-...@vger.kernel.org
The $(CPP) (do only preprocessing) macro is already defined in Makefile.
However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
in flags duplication. Which is not a big deal by itself except for
the flags which depend on other flags and the compiler checks them
as it parses the command line.

Specifically, scripts/Makefile.build:304 generates ksyms for .S files.
If clang+llvm+sanitizer are enabled, this results in

-emit-llvm-bc -fno-lto -flto -fvisibility=hidden \
-fsanitize=cfi-mfcall -fno-lto ...

in the clang command line and triggers error:

clang-13: error: invalid argument '-fsanitize=cfi-mfcall' only allowed with '-flto'

This removes unnecessary CPP redefinition. Which works fine as in most
place KBUILD_CFLAGS is passed to $CPP except
arch/powerpc/kernel/vdso64/vdso(32|64).lds (and probably some others,
not yet detected). To fix vdso, we do:
1. explicitly add -m(big|little)-endian to $CPP
2. (for clang) add $CLANG_FLAGS to $KBUILD_CPPFLAGS as otherwise clang
silently ignores -m(big|little)-endian if the building platform does not
support big endian (such as x86) so --prefix= is required.

While at this, remove some duplication from CPPFLAGS_vdso(32|64)
as cmd_cpp_lds_S has them anyway. It still puzzles me why we need -C
(preserve comments in the preprocessor output) flag here.

Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
---
Changes:
v2:
* fix KBUILD_CPPFLAGS
* add CLANG_FLAGS to CPPFLAGS
---
Makefile | 1 +
arch/powerpc/Makefile | 3 ++-
arch/powerpc/kernel/vdso32/Makefile | 2 +-
arch/powerpc/kernel/vdso64/Makefile | 2 +-
4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 72af8e423f11..13acd2183d55 100644
--- a/Makefile
+++ b/Makefile
@@ -591,6 +591,7 @@ CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
endif
CLANG_FLAGS += -Werror=unknown-warning-option
KBUILD_CFLAGS += $(CLANG_FLAGS)
+KBUILD_CPPFLAGS += $(CLANG_FLAGS)
KBUILD_AFLAGS += $(CLANG_FLAGS)
export CLANG_FLAGS
endif
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 3212d076ac6a..306bfd2797ad 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -76,6 +76,7 @@ endif

ifdef CONFIG_CPU_LITTLE_ENDIAN
KBUILD_CFLAGS += -mlittle-endian
+KBUILD_CPPFLAGS += -mlittle-endian
KBUILD_LDFLAGS += -EL
LDEMULATION := lppc
GNUTARGET := powerpcle
@@ -83,6 +84,7 @@ MULTIPLEWORD := -mno-multiple
KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
else
KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
+KBUILD_CPPFLAGS += $(call cc-option,-mbig-endian)
KBUILD_LDFLAGS += -EB
LDEMULATION := ppc
GNUTARGET := powerpc
@@ -208,7 +210,6 @@ KBUILD_CPPFLAGS += -I $(srctree)/arch/$(ARCH) $(asinstr)
KBUILD_AFLAGS += $(AFLAGS-y)
KBUILD_CFLAGS += $(call cc-option,-msoft-float)
KBUILD_CFLAGS += -pipe $(CFLAGS-y)
-CPP = $(CC) -E $(KBUILD_CFLAGS)

CHECKFLAGS += -m$(BITS) -D__powerpc__ -D__powerpc$(BITS)__
ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile
index 7d9a6fee0e3d..ea001c6df1fa 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -44,7 +44,7 @@ asflags-y := -D__VDSO32__ -s

obj-y += vdso32_wrapper.o
targets += vdso32.lds
-CPPFLAGS_vdso32.lds += -P -C -Upowerpc
+CPPFLAGS_vdso32.lds += -C

# link rule for the .so file, .lds has to be first
$(obj)/vdso32.so.dbg: $(src)/vdso32.lds $(obj-vdso32) $(obj)/vgettimeofday.o FORCE
diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile
index 2813e3f98db6..07eadba48c7a 100644
--- a/arch/powerpc/kernel/vdso64/Makefile
+++ b/arch/powerpc/kernel/vdso64/Makefile
@@ -30,7 +30,7 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
asflags-y := -D__VDSO64__ -s

targets += vdso64.lds
-CPPFLAGS_vdso64.lds += -P -C -U$(ARCH)
+CPPFLAGS_vdso64.lds += -C

# link rule for the .so file, .lds has to be first
$(obj)/vdso64.so.dbg: $(src)/vdso64.lds $(obj-vdso64) $(obj)/vgettimeofday.o FORCE
--
2.30.2

Nathan Chancellor

unread,
May 11, 2021, 3:18:16 PM5/11/21
to Alexey Kardashevskiy, linuxp...@lists.ozlabs.org, Christophe Leroy, Masahiro Yamada, Michael Ellerman, Michal Marek, Nicholas Piggin, Nick Desaulniers, clang-bu...@googlegroups.com, linux-...@vger.kernel.org, linux-...@vger.kernel.org
This is going to cause flag duplication, which would be nice to avoid. I
do not know if we can get away with just adding $(CLANG_FLAGS) to
KBUILD_CPPFLAGS instead of KBUILD_CFLAGS though. It seems like this
assignment might be better in arch/powerpc/Makefile with the
KBUILD_CPPFLAGS additions there.

Cheers,
Nathan

Segher Boessenkool

unread,
May 11, 2021, 7:19:41 PM5/11/21
to Alexey Kardashevskiy, Michal Marek, linux-...@vger.kernel.org, Masahiro Yamada, Nick Desaulniers, linux-...@vger.kernel.org, Nicholas Piggin, Nathan Chancellor, clang-bu...@googlegroups.com, linuxp...@lists.ozlabs.org
On Tue, May 11, 2021 at 11:30:17PM +1000, Alexey Kardashevskiy wrote:
> >In any case, please mention the reasoning (and the fact that you are
> >removing these flags!) in the commit message. Thanks!
>
> but i did mention this, the last paragraph... they are duplicated.

Oh! I completely missed those few lines. Sorry for that :-(

To compensate a bit:

> It still puzzles me why we need -C
> (preserve comments in the preprocessor output) flag here.

It is so that a human can look at the output and read it. Comments are
very significant to human readers :-)


Segher

Alexey Kardashevskiy

unread,
May 11, 2021, 11:49:31 PM5/11/21
to Segher Boessenkool, Michal Marek, linux-...@vger.kernel.org, Masahiro Yamada, Nick Desaulniers, linux-...@vger.kernel.org, Nicholas Piggin, Nathan Chancellor, clang-bu...@googlegroups.com, linuxp...@lists.ozlabs.org


On 5/12/21 09:16, Segher Boessenkool wrote:
> On Tue, May 11, 2021 at 11:30:17PM +1000, Alexey Kardashevskiy wrote:
>>> In any case, please mention the reasoning (and the fact that you are
>>> removing these flags!) in the commit message. Thanks!
>>
>> but i did mention this, the last paragraph... they are duplicated.
>
> Oh! I completely missed those few lines. Sorry for that :-(

Well, I probably should have made it a separate patch anyway, I'll
repost separately.


> To compensate a bit:
>
>> It still puzzles me why we need -C
>> (preserve comments in the preprocessor output) flag here.
>
> It is so that a human can look at the output and read it. Comments are
> very significant to human readers :-)

I seriously doubt anyone ever read those :) I suspect this is to pull
all the licenses in one place and do some checking but I did not dig deep.


--
Alexey

Alexey Kardashevskiy

unread,
May 11, 2021, 11:52:48 PM5/11/21
to Nathan Chancellor, linuxp...@lists.ozlabs.org, Christophe Leroy, Masahiro Yamada, Michael Ellerman, Michal Marek, Nicholas Piggin, Nick Desaulniers, clang-bu...@googlegroups.com, linux-...@vger.kernel.org, linux-...@vger.kernel.org
It is a fair point about the duplication (which is woooow, I often see
-mbig-endian 3 - three - times) and I think I only need --prefix= there
but this is still exactly the place to do such thing as it potentially
affects all archs supporting both endianness (not many though, yeah).
Thanks,
--
Alexey

Segher Boessenkool

unread,
May 12, 2021, 6:29:47 AM5/12/21
to Alexey Kardashevskiy, Michal Marek, linux-...@vger.kernel.org, Masahiro Yamada, Nick Desaulniers, linux-...@vger.kernel.org, Nicholas Piggin, Nathan Chancellor, clang-bu...@googlegroups.com, linuxp...@lists.ozlabs.org
On Wed, May 12, 2021 at 01:48:53PM +1000, Alexey Kardashevskiy wrote:
> >Oh! I completely missed those few lines. Sorry for that :-(
>
> Well, I probably should have made it a separate patch anyway, I'll
> repost separately.

Thanks.

> >To compensate a bit:
> >
> >>It still puzzles me why we need -C
> >>(preserve comments in the preprocessor output) flag here.
> >
> >It is so that a human can look at the output and read it. Comments are
> >very significant to human readers :-)
>
> I seriously doubt anyone ever read those :)

I am pretty sure whoever wrote it did!

> I suspect this is to pull
> all the licenses in one place and do some checking but I did not dig deep.

I don't see the point in that, but :-)


Segher

Alexey Kardashevskiy

unread,
May 13, 2021, 7:59:50 AM5/13/21
to linuxp...@lists.ozlabs.org, Alexey Kardashevskiy, linux-...@vger.kernel.org, linux-...@vger.kernel.org, clang-bu...@googlegroups.com, Nick Desaulniers, Nathan Chancellor, Michal Marek, Michael Ellerman, Masahiro Yamada, Segher Boessenkool
The $(CPP) (do only preprocessing) macro is already defined in Makefile.
However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
in flags duplication. Which is not a big deal by itself except for
the flags which depend on other flags and the compiler checks them
as it parses the command line.

Specifically, scripts/Makefile.build:304 generates ksyms for .S files.
If clang+llvm+sanitizer are enabled, this results in

-emit-llvm-bc -fno-lto -flto -fvisibility=hidden \
-fsanitize=cfi-mfcall -fno-lto ...

in the clang command line and triggers error:

clang-13: error: invalid argument '-fsanitize=cfi-mfcall' only allowed with '-flto'

This removes unnecessary CPP redefinition. Which works fine as in most
place KBUILD_CFLAGS is passed to $CPP except
arch/powerpc/kernel/vdso64/vdso(32|64).lds. To fix vdso, this does:
1. add -m(big|little)-endian to $CPP
2. add target to $KBUILD_CPPFLAGS as otherwise clang ignores -m(big|little)-endian if
the building platform does not support big endian (such as x86).

Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
---
Changes:
v3:
* moved vdso cleanup in a separate patch
* only add target to KBUILD_CPPFLAGS for CLANG

v2:
* fix KBUILD_CPPFLAGS
* add CLANG_FLAGS to CPPFLAGS
---
Makefile | 1 +
arch/powerpc/Makefile | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 15b6476d0f89..5b545bef7653 100644
--- a/Makefile
+++ b/Makefile
@@ -576,6 +576,7 @@ CC_VERSION_TEXT = $(subst $(pound),,$(shell $(CC) --version 2>/dev/null | head -
ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
ifneq ($(CROSS_COMPILE),)
CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
+KBUILD_CPPFLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
endif
ifeq ($(LLVM_IAS),1)
CLANG_FLAGS += -integrated-as
--
2.30.2

Nathan Chancellor

unread,
May 13, 2021, 2:59:18 PM5/13/21
to Alexey Kardashevskiy, linuxp...@lists.ozlabs.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, clang-bu...@googlegroups.com, Nick Desaulniers, Michal Marek, Michael Ellerman, Masahiro Yamada, Segher Boessenkool
You can avoid the duplication here by just doing:

KBUILD_CPPFLAGS += $(CLANG_FLAGS)

I am still not super happy about the flag duplication but I am not sure
I can think of a better solution. If KBUILD_CPPFLAGS are always included
when building .o files, maybe we should just add $(CLANG_FLAGS) to
KBUILD_CPPFLAGS instead of KBUILD_CFLAGS?

Alexey Kardashevskiy

unread,
May 13, 2021, 9:56:10 PM5/13/21
to Nathan Chancellor, linuxp...@lists.ozlabs.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, clang-bu...@googlegroups.com, Nick Desaulniers, Michal Marek, Michael Ellerman, Masahiro Yamada, Segher Boessenkool
This has potential of duplicating even more flags which is exactly what
I am trying to avoid here.


> I am still not super happy about the flag duplication but I am not sure
> I can think of a better solution. If KBUILD_CPPFLAGS are always included
> when building .o files,


My understanding is that KBUILD_CPPFLAGS should not be added for .o. Who
does know or decide for sure about what CPPFLAGS are for? :)
--
Alexey

Masahiro Yamada

unread,
May 13, 2021, 10:43:33 PM5/13/21
to Nathan Chancellor, Alexey Kardashevskiy, linuxppc-dev, Linux Kernel Mailing List, Linux Kbuild mailing list, clang-built-linux, Nick Desaulniers, Michal Marek, Michael Ellerman, Segher Boessenkool
On Fri, May 14, 2021 at 3:59 AM Nathan Chancellor <nat...@kernel.org> wrote:
>
> On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote:
> > The $(CPP) (do only preprocessing) macro is already defined in Makefile.
> > However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
> > in flags duplication. Which is not a big deal by itself except for
> > the flags which depend on other flags and the compiler checks them
> > as it parses the command line.
> >
> > Specifically, scripts/Makefile.build:304 generates ksyms for .S files.
> > If clang+llvm+sanitizer are enabled, this results in
> >
> > -emit-llvm-bc -fno-lto -flto -fvisibility=hidden \
> > -fsanitize=cfi-mfcall -fno-lto ...
> >
> > in the clang command line and triggers error:

I do not know how to reproduce this for powerpc.
Currently, only x86 and arm64 select
ARCH_SUPPORTS_LTO_CLANG.

Is this a fix for a potential issue?
Hmm, I think including --target=* in CPP flags is sensible,
but not all CLANG_FLAGS are CPP flags.
At least, -(no)-integrated-as is not a CPP flag.

We could introduce a separate CLANG_CPP_FLAGS, but
it would require more code changes...

So, I do not have a strong opinion either way.



BTW, another approach might be to modify the linker script.


In my best guess, the reason why powerpc adding the endian flag to CPP
is this line in arch/powerpc/kernel/vdso64/vdso64.lds.S

#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
#else
OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
#endif


You can use the CONFIG option to check the endian-ness.

#ifdef CONFIG_CPU_BIG_ENDIAN
OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
#else
OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
#endif


All the big endian arches define CONFIG_CPU_BIG_ENDIAN.
(but not all little endian arches define CONFIG_CPU_LITTLE_ENDIAN)


So,
#ifdef CONFIG_CPU_BIG_ENDIAN
< big endian code >
#else
< little endian code >
#endif

works for all architectures.


Only the exception is you cannot replace the one in uapi headers.
arch/powerpc/include/uapi/asm/byteorder.h: #ifdef __LITTLE_ENDIAN__
since it is exported to userspace, where CONFIG options are not available.



BTW, various flags are historically used.

- CONFIG_CPU_BIG_ENDIAN / CONFIG_CPU_LITTLE_ENDIAN
- __BIG_ENDIAN / __LITTLE_ENDIAN
- __LITTLE_ENDIAN__ (powerpc only)



__LITTLE_ENDIAN__ is defined by powerpc gcc and clang.

My experiments...


[1] powerpc-linux-gnu-gcc -> __BIG_ENDIAN__ is defined

masahiro@grover:~$ echo | powerpc-linux-gnu-gcc -E -dM -x c - | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __BIG_ENDIAN__ 1
#define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define _BIG_ENDIAN 1
#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
#define __VEC_ELEMENT_REG_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_BIG_ENDIAN__ 4321


[2] powerpc-linux-gnu-gcc + -mlittle-endian -> __LITTLE_ENDIAN__ is defined

masahiro@grover:~$ echo | powerpc-linux-gnu-gcc -E -dM -x c -
-mlittle-endian | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
#define _LITTLE_ENDIAN 1
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __LITTLE_ENDIAN__ 1
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __VEC_ELEMENT_REG_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_BIG_ENDIAN__ 4321


[3] other arch gcc -> neither of them is defined

masahiro@grover:~$ echo | gcc -E -dM -x c - | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__

masahiro@grover:~$ echo | arm-linux-gnueabihf-gcc -E -dM -x c -
-mlittle-endian | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __ORDER_BIG_ENDIAN__ 4321

masahiro@grover:~$ echo | arm-linux-gnueabihf-gcc -E -dM -x c -
-mbig-endian | grep ENDIAN
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_PDP_ENDIAN__ 3412
#define __ARM_BIG_ENDIAN 1
#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_BIG_ENDIAN__ 4321


[4] Clang --target=powerpc-linux-gnu -> __BIG_ENDIAN__ is defined

masahiro@grover:~$ echo | ~/tools/clang-latest/bin/clang -E
--target=powerpc-linux-gnu -dM -x c - | grep ENDIAN
#define _BIG_ENDIAN 1
#define __BIG_ENDIAN__ 1
#define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412



[5] very recent Clang understands --target=powerpcle-linux-gnu -->
__LITTLE_ENDIAN__ is defined

masahiro@grover:~$ echo | ~/tools/clang-latest/bin/clang -E
--target=powerpcle-linux-gnu -dM -x c - | grep ENDIAN
#define _LITTLE_ENDIAN 1
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412


[6] very recent Clang, --target=powerpc-linux-gnu + -mlittle-endian
--> __LITTLE_ENDIAN__ is defined

masahiro@grover:~$ echo | ~/tools/clang-latest/bin/clang -E
--target=powerpc-linux-gnu -dM -x c - -mlittle-endian | grep ENDIAN
#define _LITTLE_ENDIAN 1
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412




[7] Clang, target with little endian only , -mbig-endian is ignored
masahiro@grover:~$ echo | clang -E -dM -x c - | grep ENDIAN
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412
masahiro@grover:~$ echo | clang -E -dM -x c - -mbig-endian | grep ENDIAN
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __LITTLE_ENDIAN__ 1
#define __ORDER_BIG_ENDIAN__ 4321
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_PDP_ENDIAN__ 3412


--
Best Regards
Masahiro Yamada

Masahiro Yamada

unread,
May 13, 2021, 11:11:45 PM5/13/21
to Segher Boessenkool, Alexey Kardashevskiy, Michal Marek, Linux Kbuild mailing list, Nick Desaulniers, Linux Kernel Mailing List, Nicholas Piggin, Nathan Chancellor, clang-built-linux, linuxppc-dev
On Wed, May 12, 2021 at 7:29 PM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> On Wed, May 12, 2021 at 01:48:53PM +1000, Alexey Kardashevskiy wrote:
> > >Oh! I completely missed those few lines. Sorry for that :-(
> >
> > Well, I probably should have made it a separate patch anyway, I'll
> > repost separately.
>
> Thanks.
>
> > >To compensate a bit:
> > >
> > >>It still puzzles me why we need -C
> > >>(preserve comments in the preprocessor output) flag here.
> > >
> > >It is so that a human can look at the output and read it. Comments are
> > >very significant to human readers :-)
> >
> > I seriously doubt anyone ever read those :)
>
> I am pretty sure whoever wrote it did!


Keeping comments in the pre-processed linker scripts
is troublesome.

That is why -C was removed from scripts/Makefile.build


commit 5cb0512c02ecd7e6214e912e4c150f4219ac78e0
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Thu Nov 2 14:10:37 2017 -0700

Kbuild: don't pass "-C" to preprocessor when processing linker scripts




You can entirely remove

CPPFLAGS_vdso32.lds += -P -C -Upowerpc

Alexey Kardashevskiy

unread,
May 13, 2021, 11:41:09 PM5/13/21
to Masahiro Yamada, Nathan Chancellor, linuxppc-dev, Linux Kernel Mailing List, Linux Kbuild mailing list, clang-built-linux, Nick Desaulniers, Michal Marek, Michael Ellerman, Segher Boessenkool


On 14/05/2021 12:42, Masahiro Yamada wrote:
> On Fri, May 14, 2021 at 3:59 AM Nathan Chancellor <nat...@kernel.org> wrote:
>>
>> On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote:
>>> The $(CPP) (do only preprocessing) macro is already defined in Makefile.
>>> However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results
>>> in flags duplication. Which is not a big deal by itself except for
>>> the flags which depend on other flags and the compiler checks them
>>> as it parses the command line.
>>>
>>> Specifically, scripts/Makefile.build:304 generates ksyms for .S files.
>>> If clang+llvm+sanitizer are enabled, this results in
>>>
>>> -emit-llvm-bc -fno-lto -flto -fvisibility=hidden \
>>> -fsanitize=cfi-mfcall -fno-lto ...
>>>
>>> in the clang command line and triggers error:
>
> I do not know how to reproduce this for powerpc.
> Currently, only x86 and arm64 select
> ARCH_SUPPORTS_LTO_CLANG.
>
> Is this a fix for a potential issue?

Yeah, it is work in progress to enable LTO_CLANG for PPC64:

https://github.com/aik/linux/commits/lto
This should work with .lds. But missing --target=* might still hit us
somewhere else later, these include 3 header files each and there might
be endianness dependent stuff.
Nice research :) Thanks,

>
>
> --
> Best Regards
> Masahiro Yamada
>

--
Alexey

Segher Boessenkool

unread,
May 14, 2021, 4:50:06 AM5/14/21
to Masahiro Yamada, Nathan Chancellor, Alexey Kardashevskiy, linuxppc-dev, Linux Kernel Mailing List, Linux Kbuild mailing list, clang-built-linux, Nick Desaulniers, Michal Marek, Michael Ellerman
Hi!

On Fri, May 14, 2021 at 11:42:32AM +0900, Masahiro Yamada wrote:
> In my best guess, the reason why powerpc adding the endian flag to CPP
> is this line in arch/powerpc/kernel/vdso64/vdso64.lds.S
>
> #ifdef __LITTLE_ENDIAN__
> OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
> #else
> OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
> #endif

Which is equivalent to

#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf64-powerpcle")
#else
OUTPUT_FORMAT("elf64-powerpc")
#endif

so please change that at the same time if you touch this :-)

> __LITTLE_ENDIAN__ is defined by powerpc gcc and clang.

This predefined macro is required by the newer ABIs, but all older
compilers have it as well. _LITTLE_ENDIAN is not supported on all
platforms (but it is if your compiler targets Linux, which you cannot
necessarily rely on). These macros are PowerPC-specific.

For GCC, for all targets, you can say
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
You do not need any of the other *ORDER__ macros in most cases.
See "info cpp" for the sordid details.

> [2] powerpc-linux-gnu-gcc + -mlittle-endian -> __LITTLE_ENDIAN__ is defined

You can just write -mbig and -mlittle btw. Those aren't available on
all targets, but neither are the long-winded -m{big,little}-endian
option names. Pet peeve, I know :-)

HtH,


Segher

Alexey Kardashevskiy

unread,
May 16, 2021, 11:23:19 PM5/16/21
to Segher Boessenkool, Masahiro Yamada, Michal Marek, Linux Kbuild mailing list, Nick Desaulniers, Linux Kernel Mailing List, Nathan Chancellor, clang-built-linux, linuxppc-dev


On 5/14/21 18:46, Segher Boessenkool wrote:
> Hi!
>
> On Fri, May 14, 2021 at 11:42:32AM +0900, Masahiro Yamada wrote:
>> In my best guess, the reason why powerpc adding the endian flag to CPP
>> is this line in arch/powerpc/kernel/vdso64/vdso64.lds.S
>>
>> #ifdef __LITTLE_ENDIAN__
>> OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
>> #else
>> OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
>> #endif
>
> Which is equivalent to
>
> #ifdef __LITTLE_ENDIAN__
> OUTPUT_FORMAT("elf64-powerpcle")
> #else
> OUTPUT_FORMAT("elf64-powerpc")
> #endif
>
> so please change that at the same time if you touch this :-)

"If you touch this" approach did not work well with this patch so sorry
but no ;)

and for a separate patch, I'll have to dig since when it is equal, do
you know?


>
>> __LITTLE_ENDIAN__ is defined by powerpc gcc and clang.
>
> This predefined macro is required by the newer ABIs, but all older

That's good so I'll stick to it.

> compilers have it as well. _LITTLE_ENDIAN is not supported on all
> platforms (but it is if your compiler targets Linux, which you cannot
> necessarily rely on). These macros are PowerPC-specific.
>
> For GCC, for all targets, you can say
> #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> You do not need any of the other *ORDER__ macros in most cases.
> See "info cpp" for the sordid details.
>
>> [2] powerpc-linux-gnu-gcc + -mlittle-endian -> __LITTLE_ENDIAN__ is defined
>
> You can just write -mbig and -mlittle btw. Those aren't available on
> all targets, but neither are the long-winded -m{big,little}-endian
> option names. Pet peeve, I know :-)

I am looking the same guarantees across modern enough gcc and clang and
I am not sure all of the above is valid for clang 10.0.something (or
whatever we say we support) ;)


--
Alexey

Segher Boessenkool

unread,
May 17, 2021, 3:12:38 PM5/17/21
to Alexey Kardashevskiy, Masahiro Yamada, Michal Marek, Linux Kbuild mailing list, Nick Desaulniers, Linux Kernel Mailing List, Nathan Chancellor, clang-built-linux, linuxppc-dev
Hi!

On Mon, May 17, 2021 at 01:23:11PM +1000, Alexey Kardashevskiy wrote:
> On 5/14/21 18:46, Segher Boessenkool wrote:
> >On Fri, May 14, 2021 at 11:42:32AM +0900, Masahiro Yamada wrote:
> >>In my best guess, the reason why powerpc adding the endian flag to CPP
> >>is this line in arch/powerpc/kernel/vdso64/vdso64.lds.S
> >>
> >>#ifdef __LITTLE_ENDIAN__
> >>OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
> >>#else
> >>OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc")
> >>#endif
> >
> >Which is equivalent to
> >
> >#ifdef __LITTLE_ENDIAN__
> >OUTPUT_FORMAT("elf64-powerpcle")
> >#else
> >OUTPUT_FORMAT("elf64-powerpc")
> >#endif
> >
> >so please change that at the same time if you touch this :-)
>
> "If you touch this" approach did not work well with this patch so sorry
> but no ;)
>
> and for a separate patch, I'll have to dig since when it is equal, do
> you know?

Since 1994, when the three-arg version was introduced (the one-arg
version is from 1992).

> >>__LITTLE_ENDIAN__ is defined by powerpc gcc and clang.
> >
> >This predefined macro is required by the newer ABIs, but all older
>
> That's good so I'll stick to it.

Great.

> >You can just write -mbig and -mlittle btw. Those aren't available on
> >all targets, but neither are the long-winded -m{big,little}-endian
> >option names. Pet peeve, I know :-)
>
> I am looking the same guarantees across modern enough gcc and clang and
> I am not sure all of the above is valid for clang 10.0.something (or
> whatever we say we support) ;)

-mbig/-mlittle is supported in GCC since times immemorial. Whether LLVM
supports it as well just depends on how good their emulation is, I have
no idea.


Segher
Reply all
Reply to author
Forward
0 new messages