From: Daniel Axtens <hidden> Date: 2021-02-25 03:10:46
To support Clang's CFI we need LTO. For LTO, we need to be able to compile
with the LLVM integrated assembler.
Currently, we can't.
This series gets us a bit closer, but I'm still stuck and I'm hoping
someone can point me in the right direction.
Patch 1 is a fix that can be merged at any time.
The rest of this series is pretty rough, but with it, building like this:
make CC=clang-11 LD=ld.lld-11 AR=llvm-ar-11 NM=llvm-nm-11 STRIP=llvm-strip-11 \
OBJCOPY=llvm-objcopy-11 OBJDUMP=llvm-objdump-11 READELF=llvm-readelf-11 \
HOSTCC=clang-11 HOSTCXX=clang++-11 HOSTAR=llvm-ar-11 HOSTLD=ld.lld-11 \
LLVM_IAS=1 vmlinux
on a pseries_le_defconfig without Werror works except for head-64.S,
which still fails as described in the final patch. Help would be
appreciated because it's deep magic all around.
Apart from the very very dodgy change to drop the tlbiel feature
section, none of the de-gas-ing changed the compiled binary for me
under gcc-10.2.0-13ubuntu1.
Daniel Axtens (8):
powerpc/64s/exception: Clean up a missed SRR specifier
powerpc: check for support for -Wa,-m{power4,any}
powerpc/head-64: do less gas-specific stuff with sections
powerpc/ppc_asm: use plain numbers for registers
poweprc/lib/quad: Provide macros for lq/stq
powerpc/mm/book3s64/hash: drop pre 2.06 tlbiel for clang
powerpc/purgatory: drop .machine specifier
powerpc/64/asm: don't reassign labels
arch/powerpc/Makefile | 4 +-
arch/powerpc/include/asm/head-64.h | 20 ++++----
arch/powerpc/include/asm/ppc-opcode.h | 4 ++
arch/powerpc/include/asm/ppc_asm.h | 64 +++++++++++++-------------
arch/powerpc/kernel/exceptions-64s.S | 33 ++++++-------
arch/powerpc/kernel/head_64.S | 16 +++----
arch/powerpc/lib/quad.S | 4 +-
arch/powerpc/mm/book3s64/hash_native.c | 10 ++++
arch/powerpc/purgatory/trampoline_64.S | 2 +-
9 files changed, 86 insertions(+), 71 deletions(-)
--
2.27.0
From: Daniel Axtens <hidden> Date: 2021-02-25 03:11:11
Nick's patch cleaning up the SRR specifiers in exception-64s.S
missed a single instance of EXC_HV_OR_STD. Clean that up.
Caught by clang's integrated assembler.
Fixes: 3f7fbd97d07d ("powerpc/64s/exception: Clean up SRR specifiers")
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Daniel Axtens <hidden> Date: 2021-02-25 03:11:33
LLVM's integrated assembler does not like either -Wa,-mpower4
or -Wa,-many. So just don't pass them if they're not supported.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -252,7 +252,9 @@ cpu-as-$(CONFIG_E500) += -Wa,-me500# When using '-many -mpower4' gas will first try and find a matching power4# mnemonic and failing that it will allow any valid mnemonic that GAS knows# about. GCC will pass -many to GAS when assembling, clang does not.-cpu-as-$(CONFIG_PPC_BOOK3S_64)+=-Wa,-mpower4-Wa,-many+# LLVM IAS doesn't understand either flag: https://github.com/ClangBuiltLinux/linux/issues/675+# but LLVM IAS only supports ISA >= 2.06 for Book3S 64 anyway...+cpu-as-$(CONFIG_PPC_BOOK3S_64)+=$(callas-option,-Wa$(comma)-mpower4)$(callas-option,-Wa$(comma)-many)cpu-as-$(CONFIG_PPC_E500MC)+=$(callas-option,-Wa$(comma)-me500mc)KBUILD_AFLAGS+=$(cpu-as-y)
From: Daniel Axtens <hidden> Date: 2021-02-25 03:11:56
Reopening the section without specifying the same flags breaks
the llvm integrated assembler. Don't do it: just specify all the
flags all the time.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/include/asm/head-64.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Daniel Axtens <hidden> Date: 2021-02-25 03:12:21
This is dumb but makes the llvm integrated assembler happy.
https://github.com/ClangBuiltLinux/linux/issues/764
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/include/asm/ppc_asm.h | 64 +++++++++++++++---------------
1 file changed, 32 insertions(+), 32 deletions(-)
From: Daniel Axtens <hidden> Date: 2021-02-25 03:12:50
For some reason the integrated assembler in clang-11 doesn't recognise
them. Eventually we should fix it there too.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/include/asm/ppc-opcode.h | 4 ++++
arch/powerpc/lib/quad.S | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
@@ -530,9 +532,11 @@#define PPC_DCBZL(a, b) stringify_in_c(.long PPC_RAW_DCBZL(a, b))#define PPC_DIVDE(t, a, b) stringify_in_c(.long PPC_RAW_DIVDE(t, a, b))#define PPC_DIVDEU(t, a, b) stringify_in_c(.long PPC_RAW_DIVDEU(t, a, b))+#define PPC_LQ(t, a, dq) stringify_in_c(.long PPC_RAW_LQ(t, a, dq))#define PPC_LQARX(t, a, b, eh) stringify_in_c(.long PPC_RAW_LQARX(t, a, b, eh))#define PPC_LDARX(t, a, b, eh) stringify_in_c(.long PPC_RAW_LDARX(t, a, b, eh))#define PPC_LWARX(t, a, b, eh) stringify_in_c(.long PPC_RAW_LWARX(t, a, b, eh))+#define PPC_STQ(t, a, ds) stringify_in_c(.long PPC_RAW_STQ(t, a, ds))#define PPC_STQCX(t, a, b) stringify_in_c(.long PPC_RAW_STQCX(t, a, b))#define PPC_MADDHD(t, a, b, c) stringify_in_c(.long PPC_RAW_MADDHD(t, a, b, c))#define PPC_MADDHDU(t, a, b, c) stringify_in_c(.long PPC_RAW_MADDHDU(t, a, b, c))
From: Daniel Axtens <hidden> Date: 2021-02-25 03:13:14
The llvm integrated assembler does not recognise the ISA 2.05 tlbiel
version. Eventually do this more smartly.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/mm/book3s64/hash_native.c | 10 ++++++++++
1 file changed, 10 insertions(+)
@@ -267,9 +267,14 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)va|=ssize<<8;sllp=get_sllp_encoding(apsize);va|=sllp<<5;+#if 0asmvolatile(ASM_FTR_IFSET("tlbiel %0","tlbiel %0,0",%1)::"r"(va),"i"(CPU_FTR_ARCH_206):"memory");+#endif+asmvolatile("tlbiel %0"+::"r"(va)+:"memory");break;default:/* We need 14 to 14 + i bits of va */
@@ -286,9 +291,14 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)*/va|=(vpn&0xfe);va|=1;/* L */+#if 0asmvolatile(ASM_FTR_IFSET("tlbiel %0","tlbiel %0,1",%1)::"r"(va),"i"(CPU_FTR_ARCH_206):"memory");+#endif+asmvolatile("tlbiel %0"+::"r"(va)+:"memory");break;}trace_tlbie(0,1,va,0,0,0,0);
From: Daniel Axtens <hidden> Date: 2021-02-25 03:13:37
It's ignored by future versions of llvm's integrated assembler (by not -11).
I'm not sure what it does for us in gas.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/purgatory/trampoline_64.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Daniel Axtens <hidden> Date: 2021-02-25 03:14:02
The assembler really does not like us reassigning things to the same
label:
<instantiation>:7:9: error: invalid reassignment of non-absolute variable 'fs_label'
This happens across a bunch of platforms:
https://github.com/ClangBuiltLinux/linux/issues/1043https://github.com/ClangBuiltLinux/linux/issues/1008https://github.com/ClangBuiltLinux/linux/issues/920https://github.com/ClangBuiltLinux/linux/issues/1050
There is no hope of getting this fixed in LLVM, so if we want to build
with LLVM_IAS, we need to hack around it ourselves.
For us the big problem comes from this:
\#define USE_FIXED_SECTION(sname) \
fs_label = start_##sname; \
fs_start = sname##_start; \
use_ftsec sname;
\#define USE_TEXT_SECTION()
fs_label = start_text; \
fs_start = text_start; \
.text
and in particular fs_label.
I have tried to work around it by not setting those 'variables', and
requiring that users of the variables instead track for themselves
what section they are in. This isn't amazing, by any stretch, but it
gets us further in the compilation.
I'm still stuck with the following from head_64.S:
.balign 8
p_end: .8byte _end - copy_to_here
4:
/*
* Now copy the rest of the kernel up to _end, add
* _end - copy_to_here to the copy limit and run again.
*/
addis r8,r26,(ABS_ADDR(p_end, text))@ha
ld r8,(ABS_ADDR(p_end, text))@l(r8)
add r5,r5,r8
5: bl copy_and_flush /* copy the rest */
9: b start_here_multiplatform
Clang does not like this code - in particular it complains about the addis, saying
<unknown>:0: error: expected relocatable expression
I don't know what's special about p_end, because just above we do an
ABS_ADDR(4f, text) and that seems to work just fine.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/include/asm/head-64.h | 12 +++++------
arch/powerpc/kernel/exceptions-64s.S | 31 ++++++++++++++--------------
arch/powerpc/kernel/head_64.S | 16 +++++++-------
3 files changed, 29 insertions(+), 30 deletions(-)
This is a big step back (compare 9a13a524ba37).
If you use a new enough GAS, you can use the -mregnames option and just
say "r0" directly (so not define it at all, or define it to itself).
===
addi 3,3,3
addi r3,r3,3
addi %r3,%r3,3
addi 3,3,3
addi r3,r3,r3
addi %r3,%r3,%r3
===
$ as t.s -o t.o -mregnames
t.s: Assembler messages:
t.s:6: Warning: invalid register expression
t.s:7: Warning: invalid register expression
Many people do not like bare numbers. It is a bit like not wearing
seatbelts (but so is all assembler code really: you just have to pay
attention). A better argument is that it is harder to read for people
not used to assembler code like this.
We used to have "#define r0 0" etc., and that was quite problematic.
Like that "addi r3,r3,r3" example, but also, people wrote "r0" where
only a plain 0 is allowed (like in "lwzx r3,0,r3": "r0" would be
misleading there!)
Segher
And t,ds,a here. (But it should use "s" instead of "t" preferably, and
use ___PPC_RS, because it is a source field, not a target).
It should be ((ds) & 0x3fff) << 2) as well.
Segher
The "Setting Symbols" super short chapter reads:
"A symbol can be given an arbitrary value by writing a symbol, followed
by an equals sign '=', followed by an expression. This is equivalent
to using the '.set' directive."
And ".set" has
"Set the value of SYMBOL to EXPRESSION. This changes SYMBOL's value and
type to conform to EXPRESSION. If SYMBOL was flagged as external, it
remains flagged.
You may '.set' a symbol many times in the same assembly provided that
the values given to the symbol are constants. Values that are based on
expressions involving other symbols are allowed, but some targets may
restrict this to only being done once per assembly. This is because
those targets do not set the addresses of symbols at assembly time, but
rather delay the assignment until a final link is performed. This
allows the linker a chance to change the code in the files, changing the
location of, and the relative distance between, various different
symbols.
If you '.set' a global symbol, the value stored in the object file is
the last value stored into it."
So this really should be fixed in clang: it is basic assembler syntax.
Segher
This is a big step back (compare 9a13a524ba37).
If you use a new enough GAS, you can use the -mregnames option and just
say "r0" directly (so not define it at all, or define it to itself).
===
addi 3,3,3
addi r3,r3,3
addi %r3,%r3,3
addi 3,3,3
addi r3,r3,r3
addi %r3,%r3,%r3
===
$ as t.s -o t.o -mregnames
t.s: Assembler messages:
t.s:6: Warning: invalid register expression
t.s:7: Warning: invalid register expression
Many people do not like bare numbers. It is a bit like not wearing
seatbelts (but so is all assembler code really: you just have to pay
attention). A better argument is that it is harder to read for people
not used to assembler code like this.
We used to have "#define r0 0" etc., and that was quite problematic.
Like that "addi r3,r3,r3" example, but also, people wrote "r0" where
only a plain 0 is allowed (like in "lwzx r3,0,r3": "r0" would be
misleading there!)
So an overarching comment on all of these patches is that they're not
intended to be ready to merge, nor are they necessarily what I think is
the best solution. I'm just swinging a big hammer to see how far towards
LLVM_IAS=1 I can get on powerpc, and I accept I'm going to have to come
back and clean things up.
Anyway, noted, I'll push harder on trying to get llvm to accept %rN:
there was a patch that went in after llvm-11 that should help.
Kind regards,
Daniel
And t,ds,a here. (But it should use "s" instead of "t" preferably, and
use ___PPC_RS, because it is a source field, not a target).
It should be ((ds) & 0x3fff) << 2) as well.
Ah, thank you. I'll fix this up.
Kind regards,
Daniel
The "Setting Symbols" super short chapter reads:
"A symbol can be given an arbitrary value by writing a symbol, followed
by an equals sign '=', followed by an expression. This is equivalent
to using the '.set' directive."
And ".set" has
"Set the value of SYMBOL to EXPRESSION. This changes SYMBOL's value and
type to conform to EXPRESSION. If SYMBOL was flagged as external, it
remains flagged.
You may '.set' a symbol many times in the same assembly provided that
the values given to the symbol are constants. Values that are based on
expressions involving other symbols are allowed, but some targets may
restrict this to only being done once per assembly. This is because
those targets do not set the addresses of symbols at assembly time, but
rather delay the assignment until a final link is performed. This
allows the linker a chance to change the code in the files, changing the
location of, and the relative distance between, various different
symbols.
If you '.set' a global symbol, the value stored in the object file is
the last value stored into it."
So this really should be fixed in clang: it is basic assembler syntax.
No doubt I have explained this poorly.
LLVM does allow some things, this builds fine for example:
.set foo, 8192
addi %r3, %r3, foo
.set foo, 1234
addi %r3, %r3, foo
However, this does not:
a:
.set foo, a
addi %r3, %r3, foo@l
b:
.set foo, b
addi %r3, %r3, foo-a
clang -target ppc64le -integrated-as foo.s -o foo.o -c
foo.s:5:11: error: invalid reassignment of non-absolute variable 'foo' in '.set' directive
.set foo, b
^
gas otoh, has no issues with reassignment:
$ powerpc64-linux-gnu-as foo.s -c -o foo.o
$ powerpc64-linux-gnu-objdump -dr foo.o
foo.o: file format elf64-powerpc
Disassembly of section .text:
0000000000000000 <a>:
0: 38 63 00 00 addi r3,r3,0
2: R_PPC64_ADDR16_LO .text
0000000000000004 <b>:
4: 38 63 00 04 addi r3,r3,4
It seems the llvm assembler only does a single pass, so they're not keen
on trying to support reassigning labels with non-absolute values.
Kind regards,
Daniel
From: Michael Ellerman <hidden> Date: 2021-03-14 10:04:25
On Thu, 25 Feb 2021 14:09:58 +1100, Daniel Axtens wrote:
To support Clang's CFI we need LTO. For LTO, we need to be able to compile
with the LLVM integrated assembler.
Currently, we can't.
This series gets us a bit closer, but I'm still stuck and I'm hoping
someone can point me in the right direction.
[...]
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-03-19 01:33:10
Excerpts from Daniel Axtens's message of February 25, 2021 1:10 pm:
quoted hunk
LLVM's integrated assembler does not like either -Wa,-mpower4
or -Wa,-many. So just don't pass them if they're not supported.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -252,7 +252,9 @@ cpu-as-$(CONFIG_E500) += -Wa,-me500# When using '-many -mpower4' gas will first try and find a matching power4# mnemonic and failing that it will allow any valid mnemonic that GAS knows# about. GCC will pass -many to GAS when assembling, clang does not.-cpu-as-$(CONFIG_PPC_BOOK3S_64)+=-Wa,-mpower4-Wa,-many+# LLVM IAS doesn't understand either flag: https://github.com/ClangBuiltLinux/linux/issues/675+# but LLVM IAS only supports ISA >= 2.06 for Book3S 64 anyway...+cpu-as-$(CONFIG_PPC_BOOK3S_64)+=$(callas-option,-Wa$(comma)-mpower4)$(callas-option,-Wa$(comma)-many)cpu-as-$(CONFIG_PPC_E500MC)+=$(callas-option,-Wa$(comma)-me500mc)KBUILD_AFLAGS+=$(cpu-as-y)
I'm wondering why we even have this now. Kbuild's "AS" command goes
through the C compiler now with relevant options like -mcpu. I assume it
used to be useful for cross compiling when as was called directly but
I'm not sure.
Thanks,
Nick
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-03-19 01:36:00
Excerpts from Daniel Axtens's message of February 25, 2021 1:10 pm:
Reopening the section without specifying the same flags breaks
the llvm integrated assembler. Don't do it: just specify all the
flags all the time.
I don't have a problem with this but llvm might want to track the issue
if it aims to be compatible with gas if you haven't alread opened an
issue.
When you fix the patch (perhaps add a quick comment as well?), then
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Thanks,
Nick
This is a big step back (compare 9a13a524ba37).
If you use a new enough GAS, you can use the -mregnames option and just
say "r0" directly (so not define it at all, or define it to itself).
===
addi 3,3,3
addi r3,r3,3
addi %r3,%r3,3
addi 3,3,3
addi r3,r3,r3
addi %r3,%r3,%r3
===
$ as t.s -o t.o -mregnames
t.s: Assembler messages:
t.s:6: Warning: invalid register expression
t.s:7: Warning: invalid register expression
Many people do not like bare numbers. It is a bit like not wearing
seatbelts (but so is all assembler code really: you just have to pay
attention). A better argument is that it is harder to read for people
not used to assembler code like this.
We used to have "#define r0 0" etc., and that was quite problematic.
Like that "addi r3,r3,r3" example, but also, people wrote "r0" where
only a plain 0 is allowed (like in "lwzx r3,0,r3": "r0" would be
misleading there!)
So an overarching comment on all of these patches is that they're not
intended to be ready to merge, nor are they necessarily what I think is
the best solution. I'm just swinging a big hammer to see how far towards
LLVM_IAS=1 I can get on powerpc, and I accept I'm going to have to come
back and clean things up.
Anyway, noted, I'll push harder on trying to get llvm to accept %rN:
there was a patch that went in after llvm-11 that should help.
If you put it under ifdef CONFIG_CC_IS_CLANG in the meantime I think
that would be okay. Then we get error checking with gcc compiles and
llvm at least builds with its assembler which would be nice.
Thanks,
Nick
@@ -267,9 +267,14 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)va|=ssize<<8;sllp=get_sllp_encoding(apsize);va|=sllp<<5;+#if 0asmvolatile(ASM_FTR_IFSET("tlbiel %0","tlbiel %0,0",%1)::"r"(va),"i"(CPU_FTR_ARCH_206):"memory");+#endif+asmvolatile("tlbiel %0"+::"r"(va)+:"memory");break;default:/* We need 14 to 14 + i bits of va */
@@ -286,9 +291,14 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)*/va|=(vpn&0xfe);va|=1;/* L */+#if 0asmvolatile(ASM_FTR_IFSET("tlbiel %0","tlbiel %0,1",%1)::"r"(va),"i"(CPU_FTR_ARCH_206):"memory");+#endif+asmvolatile("tlbiel %0"+::"r"(va)+:"memory");break;}trace_tlbie(0,1,va,0,0,0,0);
The "Setting Symbols" super short chapter reads:
"A symbol can be given an arbitrary value by writing a symbol, followed
by an equals sign '=', followed by an expression. This is equivalent
to using the '.set' directive."
And ".set" has
"Set the value of SYMBOL to EXPRESSION. This changes SYMBOL's value and
type to conform to EXPRESSION. If SYMBOL was flagged as external, it
remains flagged.
You may '.set' a symbol many times in the same assembly provided that
the values given to the symbol are constants. Values that are based on
expressions involving other symbols are allowed, but some targets may
restrict this to only being done once per assembly. This is because
those targets do not set the addresses of symbols at assembly time, but
rather delay the assignment until a final link is performed. This
allows the linker a chance to change the code in the files, changing the
location of, and the relative distance between, various different
symbols.
If you '.set' a global symbol, the value stored in the object file is
the last value stored into it."
So this really should be fixed in clang: it is basic assembler syntax.
No doubt I have explained this poorly.
LLVM does allow some things, this builds fine for example:
.set foo, 8192
addi %r3, %r3, foo
.set foo, 1234
addi %r3, %r3, foo
However, this does not:
a:
.set foo, a
addi %r3, %r3, foo@l
b:
.set foo, b
addi %r3, %r3, foo-a
clang -target ppc64le -integrated-as foo.s -o foo.o -c
foo.s:5:11: error: invalid reassignment of non-absolute variable 'foo' in '.set' directive
.set foo, b
^
So that does seem to be allowed by the specification.
I don't have a huge problem with the patch actually, doesn't seem too
bad.
Thanks,
Nick
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2021-03-19 10:54:25
Nicholas Piggin [off-list ref] writes:
Excerpts from Daniel Axtens's message of February 25, 2021 1:10 pm:
quoted
LLVM's integrated assembler does not like either -Wa,-mpower4
or -Wa,-many. So just don't pass them if they're not supported.
Signed-off-by: Daniel Axtens <redacted>
---
arch/powerpc/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
@@ -252,7 +252,9 @@ cpu-as-$(CONFIG_E500) += -Wa,-me500# When using '-many -mpower4' gas will first try and find a matching power4# mnemonic and failing that it will allow any valid mnemonic that GAS knows# about. GCC will pass -many to GAS when assembling, clang does not.-cpu-as-$(CONFIG_PPC_BOOK3S_64)+=-Wa,-mpower4-Wa,-many+# LLVM IAS doesn't understand either flag: https://github.com/ClangBuiltLinux/linux/issues/675+# but LLVM IAS only supports ISA >= 2.06 for Book3S 64 anyway...+cpu-as-$(CONFIG_PPC_BOOK3S_64)+=$(callas-option,-Wa$(comma)-mpower4)$(callas-option,-Wa$(comma)-many)cpu-as-$(CONFIG_PPC_E500MC)+=$(callas-option,-Wa$(comma)-me500mc)KBUILD_AFLAGS+=$(cpu-as-y)
I'm wondering why we even have this now. Kbuild's "AS" command goes
through the C compiler now with relevant options like -mcpu.
It uses $(CC) but it doesn't pass it $CFLAGS AFAIK. So it would use
whatever the compiler default is for -mcpu etc. I think.
I assume it used to be useful for cross compiling when as was called
directly but I'm not sure.
We still use it directly in vdso32/Makefile.
cheers
@@ -267,9 +267,14 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)va|=ssize<<8;sllp=get_sllp_encoding(apsize);va|=sllp<<5;+#if 0asmvolatile(ASM_FTR_IFSET("tlbiel %0","tlbiel %0,0",%1)::"r"(va),"i"(CPU_FTR_ARCH_206):"memory");+#endif+asmvolatile("tlbiel %0"+::"r"(va)+:"memory");break;default:/* We need 14 to 14 + i bits of va */
@@ -286,9 +291,14 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)*/va|=(vpn&0xfe);va|=1;/* L */+#if 0asmvolatile(ASM_FTR_IFSET("tlbiel %0","tlbiel %0,1",%1)::"r"(va),"i"(CPU_FTR_ARCH_206):"memory");+#endif+asmvolatile("tlbiel %0"+::"r"(va)+:"memory");break;}trace_tlbie(0,1,va,0,0,0,0);
From: Nicholas Piggin <npiggin@gmail.com> Date: 2021-03-22 18:11:48
Excerpts from Christophe Leroy's message of March 23, 2021 2:49 am:
Le 19/03/2021 à 03:01, Nicholas Piggin a écrit :
quoted
Excerpts from Daniel Axtens's message of February 25, 2021 1:10 pm:
quoted
The llvm integrated assembler does not recognise the ISA 2.05 tlbiel
version. Eventually do this more smartly.
The whole thing with TLBIE and TLBIEL in this file seems a bit too
clever. We should have PPC_TLBIE* macros for all of them.
I was expecting to drop PPC_* macros as much as possible taking into account the later binutils
support most of them (https://github.com/linuxppc/issues/issues/350). Was not expecting to go the
other direction.
The problem in this file is we generate 3 different tlbie and tlbiel
instructions with the same mnemonic corresponding to different ISA
versions.
This might actually be the one good place to use .machine to make sure
the assembler generates the right thing. I'm not entirely sure it is
foolproof because some of the times the instruction variant is inferred
by the number of arguments it has yet arguments can be implicit. PPC_
define would be exactly explicit.
But if it can be made reasonably robust with .machine then I'd be okay
with that too.
Thanks,
Nick
Hi!
On Tue, Mar 23, 2021 at 04:11:10AM +1000, Nicholas Piggin wrote:
The problem in this file is we generate 3 different tlbie and tlbiel
instructions with the same mnemonic corresponding to different ISA
versions.
This might actually be the one good place to use .machine to make sure
the assembler generates the right thing.
Yes, but then hide that in some macro.
(And "the one good place"? I protest!)
I'm not entirely sure it is
foolproof because some of the times the instruction variant is inferred
by the number of arguments it has yet arguments can be implicit. PPC_
define would be exactly explicit.
The variants with fewer operands have those coded as 0 in the
instruction. All of this is backwards compatible.
But if it can be made reasonably robust with .machine then I'd be okay
with that too.
Since you should do a macro (or inline) for it anyway, you could just
do .long, all the nastiness is in one place anyway then, it won't make
much difference what you do. It should be documented there as well :-)
Segher