Messages in this thread | | | Date | Wed, 6 May 2020 08:45:56 -0700 | From | Fangrui Song <> | Subject | Re: [PATCH] arm64: disable patchable function entry on big-endian clang builds |
| |
On 2020-05-06, Nathan Chancellor wrote: >On Wed, May 06, 2020 at 12:22:58PM +0200, Arnd Bergmann wrote: >> On Wed, May 6, 2020 at 5:45 AM Nathan Chancellor >> <natechancellor@gmail.com> wrote: >> > On Tue, May 05, 2020 at 07:42:43PM +0200, Torsten Duwe wrote: >> > > On Tue, 5 May 2020 15:25:56 +0100 Mark Rutland <mark.rutland@arm.com> wrote: >> > > > On Tue, May 05, 2020 at 04:12:36PM +0200, Arnd Bergmann wrote: >> > > > This practically rules out a BE distro kernel with things like PAC, >> > > > which isn't ideal. >> > >> > To be fair, are there big endian AArch64 distros? >> > >> > https://wiki.debian.org/Arm64Port: "There is also a big-endian version >> > of the architecture/ABI: aarch64_be-linux-gnu but we're not supporting >> > that in Debian (so there is no corresponding Debian architecture name) >> > and hopefully will never have to. Nevertheless you might want to check >> > for this by way of completeness in upstream code." >> > >> > OpenSUSE and Fedora don't appear to have support for big endian. >> >> I don't think any of the binary distros ship big endian ARM64. There are >> a couple of users that tend to build everything from source using Yocto >> or similar embedded distros, but as far as I can tell this is getting less >> common over time as applications get ported to be compatible with >> big-endian, or get phased out and replaced by code running on regular >> little-endian systems. >> >> The users we see today are likely in telco, military or aerospace >> settings (While earth is mostly little-endian these days, space is >> definitely big-endian) that got ported from big-endian hardware, but >> often with a high degree of customization and long service life. > >Ah yes, that makes sense, thanks for the information and background. >Helps orient myself for the future. > >> My policy for Arm specific kernel code submissions is generally that >> it should be written so it can work on either big-endian or little-endian >> using the available abstractions (just like any architecture independent >> code), but I don't normally expect it to be tested on big endian. >> >> There are some important examples of code that just doesn't work >> on big-endian because it's far too hard, e.g. the UEFI runtime services. >> That is also ok, if anyone really needs it, they can do the work. >> >> > > I suggest to get a quote from clang folks first about their schedule and >> > > regarded importance of patchable-function-entries on BE, and leave it as >> > > is: broken on certain clang configurations. It's not the kernel's fault. >> > >> > We can file an upstream PR (https://bugs.llvm.org) to talk about this >> > (although I've CC'd Fangrui) but you would rather the kernel fail to >> > work properly than prevent the user from being able to select that >> > option? Why even have the "select" or "depends on" keyword then?
Created https://reviews.llvm.org/D79495 to allow the function attribute 'patchable_function_entry' on aarch64_be. I think -fpatchable-function-entry= just works.
Note, LLD does not support aarch64_be (https://github.com/ClangBuiltLinux/linux/issues/380).
>> I definitely want all randconfig kernels to build without warnings, >> and I agree with you that making it just fail at build time is not >> a good solution. >> >> > That said, I do think we should hold off on this patch until we hear >> > from the LLVM developers. >> >> +1 >> >> Arnd > >Glad we are on the same page. > >Cheers, >Nathan
| |