powerpc/64be: use ELFv2 ABI for big endian kernels
Nicholas Piggin
reviewerRFC PATCH 1/1 powerpc/64be: use ELFv2 ABI for big endian kernels
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
Thanks,
Nick
--- arch/powerpc/Makefile | 15 +++++---------- arch/powerpc/boot/Makefile | 2 +- 2 files changed, 6 insertions(+), 11 deletions(-)
arch/powerpc/Makefile +5 -10
@@ -72,18 +72,19 @@ GNUTARGET := powerpc MULTIPLEWORD := -mmultiple endif +ifeq ($(CONFIG_PPC64),y) +cflags-y += $(call cc-option,-mabi=elfv2) +aflags-y += $(call cc-option,-mabi=elfv2) +endif + cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian) -cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1) cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian -cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2 ifneq ($(cc-name),clang) cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align endif aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian) -aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1) aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian -aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2 ifeq ($(HAS_BIARCH),y) override AS += -a$(BITS)
@@ -113,14 +114,8 @@ endif endif CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no) -ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc)) AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2) -else -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcall-aixdesc) -CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) -AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) -endif CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,$(call cc-option,-mminimal-toc)) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions) CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD)
arch/powerpc/boot/Makefile +1 -1
@@ -33,7 +33,7 @@ BOOTCFLAGS += -m64 endif ifdef CONFIG_CPU_BIG_ENDIAN BOOTCFLAGS += -mbig-endian -BOOTCFLAGS += $(call cc-option,-mabi=elfv1) +BOOTCFLAGS += $(call cc-option,-mabi=elfv2) else BOOTCFLAGS += -mlittle-endian BOOTCFLAGS += $(call cc-option,-mabi=elfv2)
Signature · 1 line
2.10.2
Quoted 3 lines · Nicholas Piggin
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
Does this have implications w.r.t interfaces to
1. openfirmware/skiboot
2. glibc/vdso
Keen to find out as well
Balbir Singh.
Quoted 2 lines · Nicholas Piggin
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
There are no fundamental reasons of course, ABIs are largely just conventions, not laws of nature.
Segher
Nicholas Piggin
reviewerQuoted 10 lines · On Wed, 23 Nov 2016 08:38:34 -0600 Segher Boessenkool…
Quoted 2 lines · Nicholas Piggin
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
There are no fundamental reasons of course, ABIs are largely just conventions, not laws of nature.
That's a very good reason! I didn't think of that, I'll drop the idea.
Thanks,
Nick
Quoted 7 lines · Segher Boessenkool
Quoted 2 lines · Nicholas Piggin
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Is this actually unsupported by gcc? The ppc64 musl libc port is ABI v2 only so they use it on BE too. Buildroot forces ABI v2 to be used for all of userspace when musl is selected as the libc for this reason so it's not completely used in the wild. It's still pretty niche though...
Quoted 11 lines · Oliver O'Halloran
Quoted 7 lines · Segher Boessenkool
Quoted 2 lines · Nicholas Piggin
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).
It is supported as in, "it is a feature a user can enable". It is unsupported as in, "we do not know if it works".
Quoted 1 line
The ppc64 musl libc port is ABI v2 only so they use it on BE too.
Interesting! I've never seen a PowerPC musl in the wild though.
Quoted 4 lines
Buildroot forces ABI v2 to be used
for all of userspace when musl is selected as the libc for this reason so it's not completely used in the wild. It's still pretty niche though...
The point remains that the kernel will be the only non-niche user of ABIv2 on BE if they choose to use it. I don't expect many problems, but it is uncharted territory. YMMV, etc.
We (GCC) of course will be happy if you (Linux) wants to be guinea pig for this. But don't say we didn't warn you ;-)
Segher
Michael Ellerman
reviewerQuoted 11 lines · Segher Boessenkool
Quoted 10 lines · Oliver O'Halloran
Quoted 7 lines · Segher Boessenkool
Quoted 2 lines · Nicholas Piggin
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
cheers
Quoted 15 lines · Michael Ellerman
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).
Quoted 3 lines
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about.
How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead!
Which isn't to say you should not do this -- just think twice before doing so. And wear a life vest.
Segher
Nicholas Piggin
reviewerQuoted 23 lines · On Thu, 24 Nov 2016 17:17:16 -0600 Segher Boessenkool…
Quoted 15 lines · Michael Ellerman
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).Quoted 3 lines
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about.
Quoted 7 lines
How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead!
Which isn't to say you should not do this -- just think twice before doing so. And wear a life vest.
Other than curiosity, only two reasons for the kernel to enable it:
either it helps end users, or it allows us to get rid of elfv1 support (eventually). Both would require gcc to have some base amount of testing.
So unless an interested BE user pops up, it remains a curiosity.
Thanks,
Nick
Michael Ellerman
reviewerQuoted 31 lines · Nicholas Piggin
Quoted 28 lines · On Thu, 24 Nov 2016 17:17:16 -0600 Segher Boessenkool…
Quoted 15 lines · Michael Ellerman
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).Quoted 3 lines
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about.
How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead!
Quoted 6 lines
Quoted 2 lines
Which isn't to say you should not do this -- just think twice before doing so. And wear a life vest.
Other than curiosity, only two reasons for the kernel to enable it:
either it helps end users, or it allows us to get rid of elfv1 support (eventually). Both would require gcc to have some base amount of testing.
I think it might be worth adding as option, as long as it's not too intrusive. We could then put it in our CI and at least keep an eye on whether it continues to work.
Using ABIv1 does have user visible effects, ie. dot symbols show up in traces and so on. So getting rid of that would be nice.
Having said that, perf and other tools are currently built to assume BE==ABIv1, so breaking that assumption would possibly cause more trouble.
I guess the other question is when did ABIv2 land in the toolchain, ie. how many years do we have to wait until we can mandate it.
cheers
Nicholas Piggin
reviewerQuoted 36 lines · On Fri, 25 Nov 2016 13:08:19 +1100 Michael Ellerman <[email protected]> wrote:
Quoted 34 lines · Nicholas Piggin
Quoted 30 lines · On Thu, 24 Nov 2016 17:17:16 -0600 Segher Boessenkool…
Quoted 15 lines · Michael Ellerman
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).Quoted 3 lines
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about.
How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead!
Which isn't to say you should not do this -- just think twice before doing so. And wear a life vest.
Quoted 7 lines
Quoted 3 lines
Other than curiosity, only two reasons for the kernel to enable it:
either it helps end users, or it allows us to get rid of elfv1 support (eventually). Both would require gcc to have some base amount of testing.I think it might be worth adding as option, as long as it's not too intrusive. We could then put it in our CI and at least keep an eye on whether it continues to work.
If you're willing to take it, sure. I'll resubmit it with a default-n config option hidden away somewhere.
Quoted 7 lines
Using ABIv1 does have user visible effects, ie. dot symbols show up in traces and so on. So getting rid of that would be nice.
Having said that, perf and other tools are currently built to assume BE==ABIv1, so breaking that assumption would possibly cause more trouble.
We can make it clear it's experimental/not supported, but things like that could probably be cleaned up slowly. They should depend on elf version rather than endian anyway.
Quoted 3 lines
I guess the other question is when did ABIv2 land in the toolchain, ie. how many years do we have to wait until we can mandate it.
I think gcc 4.9, binutils 2.24, early 2014.
But if we've never been testing with those older toolchains we're a bit behind the 8 ball. Still, the second best time to plant the tree is now...
Thanks,
Nick
Michael Ellerman
reviewerQuoted 43 lines · Nicholas Piggin
Quoted 40 lines · On Fri, 25 Nov 2016 13:08:19 +1100 Michael Ellerman <[email protected]> wrote:
Quoted 37 lines · Nicholas Piggin
Quoted 23 lines · On Thu, 24 Nov 2016 17:17:16 -0600 Segher Boessenkool…
Quoted 15 lines · Michael Ellerman
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).Quoted 3 lines
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about.
Quoted 7 lines
How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead!
Which isn't to say you should not do this -- just think twice before doing so. And wear a life vest.
Other than curiosity, only two reasons for the kernel to enable it:
either it helps end users, or it allows us to get rid of elfv1 support (eventually). Both would require gcc to have some base amount of testing.
Quoted 6 lines
Quoted 3 lines
I think it might be worth adding as option, as long as it's not too intrusive. We could then put it in our CI and at least keep an eye on whether it continues to work.
If you're willing to take it, sure. I'll resubmit it with a default-n config option hidden away somewhere.
I think so, unless we find that the size of the patch grows once we start testing it more.
Quoted 10 lines
Quoted 6 lines
Using ABIv1 does have user visible effects, ie. dot symbols show up in traces and so on. So getting rid of that would be nice.
Having said that, perf and other tools are currently built to assume BE==ABIv1, so breaking that assumption would possibly cause more trouble.
We can make it clear it's experimental/not supported, but things like that could probably be cleaned up slowly. They should depend on elf version rather than endian anyway.
They should, but that assumes you have the vmlinux ELF, or some other way to query the ABI of the kernel which may not always be the case. But it's probably solvable.
Quoted 7 lines
Quoted 2 lines
I guess the other question is when did ABIv2 land in the toolchain, ie. how many years do we have to wait until we can mandate it.
I think gcc 4.9, binutils 2.24, early 2014.
But if we've never been testing with those older toolchains we're a bit behind the 8 ball. Still, the second best time to plant the tree is now...
True and true.
cheers
Michael Ellerman
reviewerQuoted 20 lines · Segher Boessenkool
Quoted 15 lines · Michael Ellerman
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Question, are there any fundamental reasons we shouldn't use the ELFv2 ABI to build big endian kernels if the compiler supports it?
No one uses ELFv2 for BE in production, and it isn't thoroughly tested at all, not even regularly tested. "Not supported", as far as GCC is concerned (or any of the distros AFAIK).
Quoted 7 lines
Quoted 1 line
Is this actually unsupported by gcc?
It may or may not work. We of course try to keep it working, or make it work if it doesn't now. But it isn't regularly tested, and it isn't a target that is considered for the release criteria (see
https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e. ABIv1 for BE, ABIv2 for LE).Quoted 3 lines
It doesn't actually say that though. It just says powerpc64-unknown-linux-gnu. So how is someone, say the musl folks, supposed to know that BE ABIv2 is not supported?
Quoted 7 lines
Because their target is powerpc64*-*-linux-musl instead? It is not on the release criteria list, it is not something we make any claims about.
How would you know -m32 -mlittle is not well tested at all? It is in much the same boat: unusual combinations of options, and unusual configurations, are not well tested. You have to build a separate C library just to get started with it, that should tell you there are some rough waters ahead!
Yeah OK, I guess that's the part that's confusing me.
Because we're hairy chested kernel programmers we don't actually build a C library at all. So we don't get that hint that we're using an odd combination, we just configure the toolchain, build it and off we go.
cheers
Quoted 3 lines · Michael Ellerman
Because we're hairy chested kernel programmers we don't actually build a C library at all. So we don't get that hint that we're using an odd combination, we just configure the toolchain, build it and off we go.
Right, I keep forgetting that kernel developers never read any documentation either :-P
Segher